Skip to content

use "go-version-file" for actions/setup-go#454

Open
majewsky wants to merge 1 commit intomainfrom
go-version-file
Open

use "go-version-file" for actions/setup-go#454
majewsky wants to merge 1 commit intomainfrom
go-version-file

Conversation

@majewsky
Copy link
Contributor

@kayrus pointed out this setting in sapcc/maintenance-controller#369 (comment), and its specification sounds like what we want. This would be a nice way to reduce some noise in the git log because we don't have to change version strings all the time when new Go versions are released.

@majewsky majewsky requested a review from a team as a code owner February 27, 2026 10:38
@github-actions
Copy link
Contributor

Merging this branch will not change overall coverage

Impacted Packages Coverage Δ 🤖
github.com/sapcc/go-makefile-maker/internal/ghworkflow 0.00% (ø)

Coverage by file

Changed files (no unit tests)

Changed File Coverage Δ Total Covered Missed 🤖
github.com/sapcc/go-makefile-maker/internal/ghworkflow/utils.go 0.00% (ø) 0 0 0

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.

Copy link

@SchwarzM SchwarzM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@majewsky
Copy link
Contributor Author

FYI, I will discuss this with Sandro on Monday. He has voiced reservations. Please do not merge until then.

@majewsky
Copy link
Contributor Author

majewsky commented Feb 27, 2026

The concern that Sandro raises (summarizing from a DM thread) is that, if go.mod has e.g. go 1.25.0 instead of go 1.25 (which is not all that uncommon), then it will stay pinned on Go 1.25.0. For running tests, this is not a big deal, but in repos where we use govulncheck, it will scream about vulnerabilities in std that were fixed in Go 1.25.x for x > 0.

Also, there may be concerns about caching of action outputs that would cause runs to get stuck on old Go versions even if it could theoretically choose a newer bugfix version, were it not for the caching.

@kayrus
Copy link

kayrus commented Feb 27, 2026

@majewsky for me the go mod tidy behavior looks like magic. sometimes it modifies the go.mod file with go 1.25.0, sometimes with go 1.25, sometimes with toolchain 1.25.XX. I tried it with similar open-source projects and the result was different. I still don't know the pattern.

@SuperSandro2000
Copy link
Member

toolchain was removed in a release a few months ago, it should no longer does that.

I think we get 1.25.0 if any dep is using that unless we are one minor version higher. If any dep is using 1.25.1 we get at least that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants