Add workflow to update go mod version. #928
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a workflow to update the version of
go
and thetoolchain
ingo.mod
. It also adds the associated failure labels for when this job fails.See https://github.com/orgs/paketo-buildpacks/discussions/283
Use cases
We want to keep the
toolchain go1.X.Y
line up to date with the latest version of go available, as that is the actual version of thego
toolchain that will be used to build the module. If this line is present,go
will guarantee to build with this version ofgo
toolchain, regardless of what version is provided in CI. Essentially this line locks down the version of go used to build a module at a specific point in time. By keeping it up to date, we guarantee that we're always building with the latest version ofgo
.One caveat is that this
toolchain
line requires a minimum version of thego 1.x
line in thego.mod
- specifically it requiresgo 1.21
or greater. So this workflow will also bump that version if it is lower than1.21
. It will ignore the line if it is greater than or equal togo 1.21
.I think running this job once per week is sufficient. Go doesn't release patch versions that frequently, and we don't release buildpacks more frequently than weekly. We can always invoke it directly with the
workflow_dispatch
in case of a critical CVE fix between scheduled runs.Checklist