Overriding go-version with latest regardless of settings

[ross-spencer]

Description:

I have the following configured:

    - name: Set up Go
      uses: actions/setup-go@v5
      with:
        go-version: '1.22'
    - run: go version

But in GitHub the workflow is always downloading 1.23.3:

Run actions/setup-go@v5
Setup go version spec 1.22
Found in cache @ /opt/hostedtoolcache/go/1.22.9/x64
Added go to the path
Successfully set up Go version 1.22
go: downloading go1.23.3 (linux/amd64)
/opt/hostedtoolcache/go/1.22.[9](https://github.com/ocfl-archive/error/actions/runs/11952824712/job/33319397499#step:4:10)/x64/bin/go env GOMODCACHE
/opt/hostedtoolcache/go/1.22.9/x64/bin/go env GOCACHE
/home/runner/go/pkg/mod
/home/runner/.cache/go-build
Cache is not found
go version go1.23.3 linux/amd64

Action version:

V5.

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:

Expected 1.22 getting 1.23.3

Repro steps:

Currently running in this PR here: https://github.com/ocfl-archive/error/pull/1/files#diff-717013d02a8afac81852f25ba8ecd3cc0ca53a7f1fe25bedebfd66d6f518d21c

Expected behavior:
A description of what you expected to happen.

Configuration of Go version should work.

Actual behavior:
A description of what is actually happening.

It looks like Go 1.22 is successfully installed and then it is overridden by 1.23. It shows up quite profoundly in this workflow because staticcheck is not compiled for 1.23.

[ross-spencer]

I've tried a few things including ignoring cache, the runner looks like this now:

Run actions/setup-go@v5
  with:
    go-version: 1.[2](https://github.com/ocfl-archive/error/actions/runs/11953409989/job/33321226432#step:4:2)2
    cache: false
    check-latest: false
    token: ***
Setup go version spec 1.22
Found in cache @ /opt/hostedtoolcache/go/1.22.9/x64
Added go to the path
Successfully set up Go version 1.22
go: downloading go1.2[3](https://github.com/ocfl-archive/error/actions/runs/11953409989/job/33321226432#step:4:3).3 (linux/amd64)
go version go1.23.3 linux/amd6[4](https://github.com/ocfl-archive/error/actions/runs/11953409989/job/33321226432#step:4:4)

go env

I wonder if it is being overridden by go.mod? (can that be explicitly ignored?)

EDIT: i'm sure i'm doing something stupid here, just can't figure out what.

[aparnajyothi-y]

Hello @ross-spencer, Thank you for creating this issue and we will look into it :)

[mahalakshmi-rekadi]

Hello @ross-spencer,
Updating the go 1.23.3 line in the go.mod file to go 1.22 is important because the go.mod file specifies the Go version required by the module. When Go commands are executed, the version specified in go.mod (1.23.3) is enforced, which can override any pre-installed version (1.22). This ensures that the module is always built and tested with the specified version, providing consistency across different environments.(When you run Go commands within the module, it will ensure that the specified version (1.23.3) is used, potentially overriding any previously installed version (1.22)).
For your reference please check below screenshot, which was resolved after updating the go 1.23.3 line in the go.mod file to go 1.22

Explicitly ignoring the go version can lead to inconsistencies and unexpected behavior, as dependencies may rely on features available only in the specified Go version.

It is best practice to update the go.mod file to match the installed version instead of ignoring it explicitly because:
1.Environment Consistency: Ensures uniformity across all environments (local, CI/CD, production), minimizing version-related discrepancies.
2.Dependency Compatibility: Guarantees that dependencies are aligned with the specified Go version, ensuring access to all relevant features and bug fixes.
3.Project Documentation: Clearly communicates the required Go version, facilitating easier setup and maintenance for all contributors.

Refer the below doc,
https://go.dev/ref/mod

Please let us know if you have any further questions or support needed.

[ross-spencer]

Thanks for looking at this in-depth @mahalakshmi-rekadi I appreciate it! I will need to think about how to perform multi-version testing but this should stabilize things for now. I will take a look at my settings again this week, this helps a lot.