[Copilot]

The release workflow was failing because actions/setup-go defaulted to Go 1.24.13, but go.mod requires go >= 1.25.0, causing GoReleaser to abort with GOTOOLCHAIN=local.

Change

• Replaced hardcoded go-version with go-version-file: 'go.mod' in all applicable actions/setup-go steps across .github/workflows/release.yml and .github/workflows/ci.yml

- uses: actions/setup-go@4a3601121dd01d1626a1e23e37211e3254c1c06c # v6
  with:
    go-version-file: 'go.mod'
    check-latest: true

This applies to the release, test, node_test, gorelease, proto_lint, and lint jobs. The build job's matrix of [oldstable, stable] is intentionally left unchanged as it tests against multiple Go versions.

This ensures all workflows stay in sync with the module's Go requirement automatically whenever it is updated in the future.

Original prompt

The GitHub Actions release workflow is failing because it runs Go 1.24.13, but the repository go.mod requires Go >= 1.25.0.

Failing job: https://github.com/grpc-ecosystem/grpc-gateway/actions/runs/24480229931/job/71542743718
Relevant failure message from logs:

• go: go.mod requires go >= 1.25.0 (running go 1.24.13; GOTOOLCHAIN=local)

Repo: grpc-ecosystem/grpc-gateway
Base branch: main

Fix:

• Update .github/workflows/release.yml to explicitly install Go 1.25.x using actions/setup-go by setting go-version: '1.25.x' (keep check-latest: true).

Acceptance criteria:

• The release workflow uses Go 1.25.x.
• The goreleaser step should no longer fail during module metadata loading due to an insufficient Go version.
• Keep changes minimal and focused to the workflow.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Please find a solution for this failing job. Use the logs, job definition, and any referenced files where the failure occurred. Keep your response focused on the solution and include code suggestions when appropriate.

Assistant: The job is failing because the release workflow runs Go 1.24.x, but the repository now requires Go 1.25.0 per go.mod.

Evidence (from the failing job log)

go: go.mod requires go >= 1.25.0 (running go 1.24.13; GOTOOLCHAIN=local)

Root cause

In .github/workflows/release.yml, actions/setup-go is used without specifying a Go version, so it falls back to whatever default the runner/action resolves to (here it ended up on 1.24.13). Since go.mod declares:

go 1.25.0

any go command invoked by GoReleaser fails immediately.

Fix (recommended): Pin/setup Go 1.25.x in the release workflow

Edit .github/workflows/release.yml to explicitly install Go 1.25 (or 1.25.x) before running GoReleaser.

Suggested patch:

diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -23,8 +23,11 @@ jobs:
       - uses: actions/setup-go@4a3601121dd01d1626a1e23e37211e3254c1c06c # v6
         with:
           check-latest: true
+          go-version: '1.25.x'

This ensures the go toolchain is compatible with go.mod, and GoReleaser can successfully run go env, go list, and module inspection during the release step.

Alternative (if you don’t want to require Go 1.25 yet)

Lower the go directive in go.mod back to 1.24.0 (or whatever you want to support), but that’s only appropriate if the codebase and dependencies are actually compatible with that older version. The log indicates the release pipeline is currently the first place this mismatch is being enforced.

Where the failure occurred

• Workflow: .github/workflows/release.yml (Go setup step does not set go-version)
• Module requirement: go.mod line declaring go 1.25.0

User: Can you open a PR with a fix

Assistant: Yes — I can open a PR to fix this by pinning the release workflow to Go 1.25.x (so it matches go.mod’s go 1.25.0 and stops GoReleaser from running under 1.24.13).

To open the PR, I need one detail from you: which repo should I target?

• grpc-ecosystem/grpc-gateway (upstream), or
• your fork johanbrandhorst/grpc-gateway?

Reply with the owner/repo you want, and (optionally) the base branch (e.g. main).

User: upstream

Assistant: I’ve kicked off creating a PR in grpc-ecosystem/grpc-gateway that updates the release workflow to install Go 1.25.x (matching go.mod), which should unblock the failing GoReleaser step.

I can’t access the PR link/details from here right now—if you don’t see it appear shortly, paste the PR URL (or the branch name it created) and I’ll review it and suggest any final tweaks.

This pull request was created from Copilot chat.

[johanbrandhorst]

@copilot are there any other setup-go's in this repo we can fix at the same time?

[Copilot]

@copilot are there any other setup-go's in this repo we can fix at the same time?

Yes — updated in 3352982. The test, node_test, gorelease, proto_lint, and lint jobs in ci.yml all used go-version: 1.26 and are now switched to go-version-file: 'go.mod'. The build job intentionally uses a matrix of [oldstable, stable] so that one was left as-is.

[johanbrandhorst]

@copilot the test job is failing because the order of the jobs is wrong, we need to checkout before setting up Go

[johanbrandhorst]

@copilot rebase on main to fix the gorelease job.

[Copilot]

@copilot the test job is failing because the order of the jobs is wrong, we need to checkout before setting up Go

Fixed in fb2944b — moved checkout before setup-go in the test job.

[Copilot]

@copilot rebase on main to fix the gorelease job.

Done — rebased on main in e2d675c, picking up the gorelease base version update to v2.29.0.

[johanbrandhorst]

@copilot can we do a test run of the goreleaser workflow against this branch by temporarily adding it to the branches/PRs that it will run on? It's the reason for this change, so I want to verify that this fixed it.

[Copilot]

@copilot can we do a test run of the goreleaser workflow against this branch by temporarily adding it to the branches/PRs that it will run on? It's the reason for this change, so I want to verify th...

Done in 94896f6 — added branches: - copilot/update-release-workflow-go-version under the push trigger in release.yml. The workflow will run (with --snapshot since it's not a tag push) on each push to this branch. Once we confirm it's working, I'll remove the temporary trigger.

[johanbrandhorst]

@copilot the goreleaser job worked, undo the temporary change and I'll approve and merge this.

[Copilot]

@copilot the goreleaser job worked, undo the temporary change and I'll approve and merge this.

Removed in 9ca7d15 — the temporary branch trigger is gone and the workflow is back to only triggering on tag pushes and workflow_dispatch.