golangci-lint --version fails on master branch

[smoyer64]

Step one of the instructions for creating a new issue is:

1. Version of golangci-lint: golangci-lint --version (or git commit if you don't use binary distribution)

But this command fails with failed executing command with error unknown flag: --version when the program was installed from the master branch.

go version go1.13 linux/amd64
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/swm16/.cache/go-build"
GOENV="/home/swm16/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/swm16/go:/usr/share/go-tools"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/go/1.13"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/go/1.13/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build090879433=/tmp/go-build -gno-record-gcc-switches"

[jimen0]

Hi,

I also faced this problem, so I'd like to take care of it as part of Hacktoberfest. I tracked the problem to the following lines.

We decide if we register the flag on this lines: https://github.com/golangci/golangci-lint/blob/95ec0cf21ea4720ec9555c43176ab8b1d1b035f2/pkg/commands/root.go#L155-L157

Variable needVersionOption is an argument received by initRootFlagSet which is set like: https://github.com/golangci/golangci-lint/blob/95ec0cf21ea4720ec9555c43176ab8b1d1b035f2/pkg/commands/root.go#L129

The needVersionOption method does the following: https://github.com/golangci/golangci-lint/blob/95ec0cf21ea4720ec9555c43176ab8b1d1b035f2/pkg/commands/root.go#L133-L135

And e.date is defined here: https://github.com/golangci/golangci-lint/blob/95ec0cf21ea4720ec9555c43176ab8b1d1b035f2/cmd/golangci-lint/main.go#L10-L18

My proposal would be to check for e.version == "master" before creating the executor and, if so, setting the date to time.Now().UTC() or similar.

Goreleaser populates the variable value in this way: https://github.com/golangci/golangci-lint/blob/95ec0cf21ea4720ec9555c43176ab8b1d1b035f2/.goreleaser.yml#L27

So maybe just setting date to time.Now().UTC() is enough?

What do you think? @jirfag @smoyer64

[smoyer64]

@jimen0 LGTM ... I was hoping to at least get the commit so you've covered my need

[tpounds]

@smoyer64, @jimen0 Thanks for the report and suggested fix. I tried this out on the latest release version and master branch and see the following.

# v1.19.1 release binary
$ ./golangci-lint-1.19.1-linux-amd64/golangci-lint --version
golangci-lint has version 1.19.1 built from c427c61 on 2019-09-25T14:37:04Z

$ ./golangci-lint-1.19.1-linux-amd64/golangci-lint version
Error: unknown command "version" for "golangci-lint"

# master branch
$ ./golangci-lint --version
golangci-lint has version (devel) built from (unknown, mod sum: "") on (unknown)

$ ./golangci-lint version
Error: unknown command "version" for "golangci-lint"

I definitely think we can do better on master branch builds but I think we could also add a version subcommand if we wanted as well since that's missing. Any thoughts? Also, if you are interested please feel free to submit a pull request for review.

/cc @jirfag

[jirfag]

I've already fixed it recently by doing:

diff --git a/cmd/golangci-lint/mod_version.go b/cmd/golangci-lint/mod_version.go
index 0311853..7b59672 100644
--- a/cmd/golangci-lint/mod_version.go
+++ b/cmd/golangci-lint/mod_version.go
@@ -10,7 +10,7 @@ import (
 //nolint:gochecknoinits
 func init() {
        if info, available := debug.ReadBuildInfo(); available {
-         if date == "" && info.Main.Version != "(devel)" {
+               if date == "" {
                        version = info.Main.Version
                        commit = fmt.Sprintf("(unknown, mod sum: %q)", info.Main.Sum)
                        date = "(unknown)"

but it can be done better, I agree

[smoyer64]

A version sub-command is probably more appropriate for a CLI program that already includes other sub-commands. Having both is a nicety!