Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compile: version "go1.16.2" does not match go tool version "go1.15.8" #107

Closed
fatedier opened this issue Mar 16, 2021 · 17 comments
Closed
Assignees
Labels
bug Something isn't working

Comments

@fatedier
Copy link

Failed case:
https://github.com/fatedier/release-test/runs/2121758524?check_suite_focus=true

- name: Set up Go
  uses: actions/setup-go@v2
  with:
    go-version: '1.16.2'

Workflow file:
https://github.com/fatedier/release-test/actions/runs/657671091/workflow

I'm not sure why there are go1.15.8 version.

@xmapst
Copy link

xmapst commented Mar 26, 2021

+1

@pmalek-sumo
Copy link

@pmalek-sumo
Copy link

Ok so I managed to solve it by specifying go to use in the build process when using https://github.com/open-telemetry/opentelemetry-collector-builder

--go string                The Go binary to use during the compilation phase (default "/usr/bin/go")

The problem is that /usr/bin/go has a different version than what is installed via the action (unless you specify the very same version to use ofc).

@zwass
Copy link

zwass commented May 31, 2021

@bryanmacfarlane this seems like a bit of a showstopper bug, causing Go 1.16 not to work without some kind of workaround.

The issue manifests when trying to run a command like go vet ./....

@zwass
Copy link

zwass commented May 31, 2021

In my case, the issue was resolved by removing $GOPATH/bin from my PATH. I wonder if the setup action fails to set the GOPATH appropriately when installing the non-default version?

@76creates
Copy link

this issue can be duct-taped like:

      run: |
        export PATH=${GOROOT}/bin:$PATH
        go version

issue I found is that GOROOT is appended at the end of the path, basically it will resolve system go in /usr/bin first if not fixed

@76creates
Copy link

this issue can be duct-taped like:

      run: |
        export PATH=${GOROOT}/bin:$PATH
        go version

issue I found is that GOROOT is appended at the end of the path, basically it will resolve system go in /usr/bin first if not fixed

Noticed that I see this issue while using act, i could not reproduce it on the Github.

@Sergey-Murtazin Sergey-Murtazin added the bug Something isn't working label Oct 21, 2021
@Sergey-Murtazin
Copy link
Contributor

Hi, @fatedier !

I've forked your repository and reproduced your issue.
It looks like this issue is not related to the setup-go action.
In the Makefile.cross-compiles file you add $(GOPATH)/bin to the beginning of the $PATH environment variable.
The GOPATH variable does not exist on the Ubuntu images and is not defined by setup-go action, so $(GOPATH)/bin resolves to /bin.

Please remove the export PATH := $(GOPATH)/bin:$(PATH) line from your Makefiles to resolve the issue.
See successful test run in my fork.

Thanks!

@fatedier
Copy link
Author

fatedier commented Nov 1, 2021

@Sergey-Murtazin Thanks for your reply.

Maybe remove export PATH := $(GOPATH)/bin:$(PATH) could work for this Makefile since it not rely on $(GOPATH)/bin.

However, i need to execute make e2e to run e2e tests in my real project. It will download ginkgo first by go install github.com/onsi/ginkgo/ginkgo@latest and then execute it from $GOPATH/bin. It works well in most of environments.

Can we set GOPATH variable in setup-go action, so users will not be affect by different environments?

@Sergey-Murtazin
Copy link
Contributor

Hi, @fatedier !

Can you please provide a public repo with minimal code which leads to this problem?
I still can't reproduce it.
My WF has a step where ginkgo is installed and run with an absence of the GOPATH variable.

@fatedier
Copy link
Author

@Sergey-Murtazin It seems setup-go already modifies PATH to include ${GOPATH}/bin ?

It works well in github action but maybe not user's local computer.

I add export PATH := $(GOPATH)/bin:$(PATH) in Makefile to cover different environments in case users may not add $GOPATH/bin to the PATH environment variable. Are there any other choice to do the same thing?

@vsafonkin
Copy link

Hi @fatedier, could you try to remove go symlink from /usr/bin as workaround in your workflow file?

- run: sudo rm /usr/bin/go

@fatedier
Copy link
Author

@vsafonkin
https://github.com/fatedier/frp/blob/dev/.github/workflows/goreleaser.yml#L22

I fix this issue by "cp -f `which go` /usr/bin/go" in my project

@Sergey-Murtazin
Copy link
Contributor

Sergey-Murtazin commented Dec 28, 2021

Hi, @fatedier

There is a problem with a symlink to the default go version on the runner in /usr/bin.
Currently, we discuss should we delete it when we use an action.

@Sergey-Murtazin Sergey-Murtazin removed their assignment Jan 31, 2022
jacobbednarz added a commit to jacobbednarz/cloudflare-go that referenced this issue Apr 6, 2022
jacobbednarz added a commit to jacobbednarz/cloudflare-go that referenced this issue Apr 7, 2022
jacobbednarz added a commit to jacobbednarz/cloudflare-go that referenced this issue Apr 7, 2022
jacobbednarz added a commit to jacobbednarz/cloudflare-go that referenced this issue Apr 7, 2022
jacobbednarz added a commit to jacobbednarz/cloudflare-go that referenced this issue Apr 7, 2022
jacobbednarz added a commit to jacobbednarz/cloudflare-go that referenced this issue Apr 7, 2022
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 19, 2022
…ion go1.17.11

Refer to actions/setup-go#107

Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 19, 2022
…ion go1.17.11

Refer to actions/setup-go#107

Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 19, 2022
…ion go1.17.11

Refer to actions/setup-go#107

Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 19, 2022
…ion go1.17.11

Refer to actions/setup-go#107

Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 19, 2022
…ion go1.17.11

Refer to actions/setup-go#107

Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 20, 2022
Items resolved:
1. fix the vet error: possible misuse of reflect.SliceHeader;
2. fix the vet error: call to (*T).Fatal from a non-test goroutine;
3. bump package golang.org/x/crypto, net and sys;
4. bump boltdb from 1.3.3 to 1.3.6;
5. remove the vendor directory;
6. remove go 1.12.17 and 1.15.15, add go 1.16.15 into pipeline;
7. bump go version to 1.16 in go.mod;
8. fix the issue: compile: version go1.16.15 does not match go tool version go1.17.11,
   refer to actions/setup-go#107;
9. fix data race on compactMainRev and watcherGauge.

Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 20, 2022
Items resolved:
1. fix the vet error: possible misuse of reflect.SliceHeader;
2. fix the vet error: call to (*T).Fatal from a non-test goroutine;
3. bump package golang.org/x/crypto, net and sys;
4. bump boltdb from 1.3.3 to 1.3.6;
5. remove the vendor directory;
6. remove go 1.12.17 and 1.15.15, add go 1.16.15 into pipeline;
7. bump go version to 1.16 in go.mod;
8. fix the issue: compile: version go1.16.15 does not match go tool version go1.17.11,
   refer to actions/setup-go#107;
9. fix data race on compactMainRev and watcherGauge;
10. fix test failure for TestLeasingTxnOwnerGet in cluster_proxy mode.

Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 21, 2022
Items resolved:
1. fix the vet error: possible misuse of reflect.SliceHeader;
2. fix the vet error: call to (*T).Fatal from a non-test goroutine;
3. bump package golang.org/x/crypto, net and sys;
4. bump boltdb from 1.3.3 to 1.3.6;
5. remove the vendor directory;
6. remove go 1.12.17 and 1.15.15, add go 1.16.15 into pipeline;
7. bump go version to 1.16 in go.mod;
8. fix the issue: compile: version go1.16.15 does not match go tool version go1.17.11,
   refer to actions/setup-go#107;
9. fix data race on compactMainRev and watcherGauge;
10. fix test failure for TestLeasingTxnOwnerGet in cluster_proxy mode.

Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 21, 2022
Items resolved:
1. fix the vet error: possible misuse of reflect.SliceHeader;
2. fix the vet error: call to (*T).Fatal from a non-test goroutine;
3. bump package golang.org/x/crypto, net and sys;
4. bump boltdb from 1.3.3 to 1.3.6;
5. remove the vendor directory;
6. remove go 1.12.17 and 1.15.15, add go 1.16.15 into pipeline;
7. bump go version to 1.16 in go.mod;
8. fix the issue: compile: version go1.16.15 does not match go tool version go1.17.11,
   refer to actions/setup-go#107;
9. fix data race on compactMainRev and watcherGauge;
10. fix test failure for TestLeasingTxnOwnerGet in cluster_proxy mode.

Signed-off-by: Benjamin Wang <wachao@vmware.com>
ahrtr added a commit to ahrtr/etcd that referenced this issue Jun 21, 2022
Items resolved:
1. fix the vet error: possible misuse of reflect.SliceHeader;
2. fix the vet error: call to (*T).Fatal from a non-test goroutine;
3. bump package golang.org/x/crypto, net and sys;
4. bump boltdb from 1.3.3 to 1.3.6;
5. remove the vendor directory;
6. remove go 1.12.17 and 1.15.15, add go 1.16.15 into pipeline;
7. bump go version to 1.16 in go.mod;
8. fix the issue: compile: version go1.16.15 does not match go tool version go1.17.11,
   refer to actions/setup-go#107;
9. fix data race on compactMainRev and watcherGauge;
10. fix test failure for TestLeasingTxnOwnerGet in cluster_proxy mode.

Signed-off-by: Benjamin Wang <wachao@vmware.com>
tjungblu pushed a commit to tjungblu/etcd that referenced this issue Sep 8, 2022
Items resolved:
1. fix the vet error: possible misuse of reflect.SliceHeader;
2. fix the vet error: call to (*T).Fatal from a non-test goroutine;
3. bump package golang.org/x/crypto, net and sys;
4. bump boltdb from 1.3.3 to 1.3.6;
5. remove the vendor directory;
6. remove go 1.12.17 and 1.15.15, add go 1.16.15 into pipeline;
7. bump go version to 1.16 in go.mod;
8. fix the issue: compile: version go1.16.15 does not match go tool version go1.17.11,
   refer to actions/setup-go#107;
9. fix data race on compactMainRev and watcherGauge;
10. fix test failure for TestLeasingTxnOwnerGet in cluster_proxy mode.

Signed-off-by: Benjamin Wang <wachao@vmware.com>
@vsafonkin vsafonkin removed their assignment Oct 31, 2022
@dsame dsame self-assigned this Mar 16, 2023
@dsame
Copy link
Contributor

dsame commented Mar 16, 2023

It is confirmed the latest action still creates a link

/usr/bin/go -> /opt/hostedtoolcache/go/1.18.10/x64/bin/go

despite the requested version is 1.16.2

@dsame
Copy link
Contributor

dsame commented Mar 20, 2023

Hi, @fatedier

There is a problem with a symlink to the default go version on the runner in /usr/bin. Currently, we discuss should we delete it when we use an action.

setup-go action should not delete or overwrite the link /usr/bin/go because this destroys the self-hosted environment.

Current version of action set the PATH variable in order $GOROOT/bin to preseed /usr/bin that ensures the correct version of go unless 3rd party tool changes the PATH.

In case if default go version (1.18.10 at the moment of this comment writing) is picked up instead of the requested the PATH variable in the build environment has to be modified like this: $GOPATH/bin:$PATH

@fatedier i am going to close the issue because it is answered, but please feel free to reopen this issue or create new one if the problem still exists.

@dsame dsame closed this as completed Mar 20, 2023
tsukumijima added a commit to tsukumijima/KonomiTV that referenced this issue Oct 16, 2023
@tanerjn
Copy link

tanerjn commented Feb 23, 2024

this issue can be duct-taped like:

      run: |
        export PATH=${GOROOT}/bin:$PATH
        go version

issue I found is that GOROOT is appended at the end of the path, basically it will resolve system go in /usr/bin first if not fixed

has solved for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

10 participants