Allow specifying golangci-lint custom output path as argument

[lukasschwab]

Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.
• I agree to follow this project's Code of Conduct

Your feature request related to a problem? Please describe

Currently golangci-lint custom write the resulting custom binary to

1. The destination and name specified in .custom-gcl.yml or equivalent.
2. ./custom-gcl by default.

When building a generic harness for custom linters — one where users bring their own .custom-gci.yml files — I want to write a script that builds a custom linter and then invokes it, regardless of the destination and name specified in YAML.

Describe the solution you'd like

I want to be able to specify an output location with a command-line argument. For example, I'd like to run

$ golangci-lint custom -v -o ./freshly-built-linter
$ ./freshly-built-linter run

This can behave analagously to the -o output argument on go build: if present, override the settings in YAML.

usage: go build [-o output] [build flags] [packages]

Describe alternatives you've considered

• Requiring an implicit correspondence between arguments to my program and the contents (name, destination) of a user's .custom-gcl.yml file.
• Parsing the .custom-gcl.yml files in my scripts to extract name and destination, to recreate the path to the build target.

Additional context

No response

Supporter

• I am a sponsor through GitHub or OpenCollective

[boring-cyborg]

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

[ldez]

Hello,

When building a generic harness for custom linters — one where users bring their own .custom-gci.yml files — I want to write a script that builds a custom linter and then invokes it, regardless of the destination and name specified in YAML.

I'm not sure to understand what to mean by "a generic harness for custom linters", can you provide more details?
Why do you want to do that? In which concrete context?

I think it's better to have a .custom-gci.yml by project.

[lukasschwab]

@ldez I'll have a concrete example for you shortly; it's a GitHub Action based on golangci/golangci-lint-action#1076 (comment).

Probably won't maintain it for long; when the official action supports custom module plugins (i.e. golangci/golangci-lint-action#1076 is resolved) there's no longer any need.

I think it's better to have a .custom-gci.yml by project.

Each repository using an action to run golangci-lint can have its own .custom-gci.yml file, and specify their own name and destination according to their local development needs. In CI, we need to locate the built custom binary to run it. The easiest way is to specify a location in the build step.

This will require tackling if/when you solve golangci/golangci-lint-action#1076 too.

Thanks for all your work on this ecosystem!

[ldez]

OK, the support of custom inside the GitHub Action will be added, I plan to work on it but after the v2.

I plan to work on 2 issues on the GitHub Action:

• large diff
• custom plugins

As your request is related to the current limitations of the GitHub Action, and I don't want to add and maintain niche and "temporarily" options, I will decline this issue.

I think I will work on this around mid and end of February (after go1.24 release and v2 release).

[lukasschwab]

@ldez would you consider a PR introducing this -o behavior if I open it?

[ldez]

No, as I said in my previous comment.

I don't want to add and maintain niche and "temporarily" options

[lukasschwab]

Don't think the proposed feature is "niche and 'temporarily'" — it's relevant to the scenario I describe, but it's a worthwhile improvement in general:

1. The minimum viable patch (below) is small and doesn't require changes to Configuration.
2. There is no need to revert this argument after Support for module plugin system via .custom-gcl.yml golangci-lint-action#1076 is closed — to the contrary, this is likely to be a step in solving that issue.
3. It makes the golangci-lint custom command behave more like what it is: a build tool. The YAML structure is not self-documenting, but golangci-lint --help is.

Anyway, it's your prerogative to decline the change; I won't argue this point further.

diff --git a/pkg/commands/custom.go b/pkg/commands/custom.go
index 1bc9f901..27117cb1 100644
--- a/pkg/commands/custom.go
+++ b/pkg/commands/custom.go
@@ -4,7 +4,9 @@ import (
 	"fmt"
 	"log"
 	"os"
+	"path"
 
+	"github.com/fatih/color"
 	"github.com/spf13/cobra"
 
 	"github.com/golangci/golangci-lint/pkg/commands/internal"
@@ -13,6 +15,10 @@ import (
 
 const envKeepTempFiles = "CUSTOM_GCL_KEEP_TEMP_FILES"
 
+var (
+	outputArgument = ""
+)
+
 type customCommand struct {
 	cmd *cobra.Command
 
@@ -33,6 +39,8 @@ func newCustomCommand(logger logutils.Log) *customCommand {
 		SilenceUsage: true,
 	}
 
+	customCmd.Flags().StringVarP(&outputArgument, "output", "o", "", color.GreenString("Path to output file"))
+
 	c.cmd = customCmd
 
 	return c
@@ -44,6 +52,12 @@ func (c *customCommand) preRunE(_ *cobra.Command, _ []string) error {
 		return err
 	}
 
+	if outputArgument != "" {
+		directory, name := path.Split(outputArgument)
+		cfg.Destination = directory
+		cfg.Name = name
+	}
+
 	err = cfg.Validate()
 	if err != nil {
 		return err