Automate Fleet release against Rancher#4796
Conversation
There was a problem hiding this comment.
Pull request overview
This PR streamlines the “release Fleet against rancher/rancher” automation by removing manual version inputs and deriving the target Rancher ref + Fleet/Chart versions programmatically, while also updating Renovate to cover the new release branch.
Changes:
- Simplified the workflow dispatch inputs to a
fleet_branchchoice and added a “compute versions” step to deriverancher_ref,new_fleet,new_chart, and whether to bump API. - Hardened
release-against-rancher.sh(stricter bash flags, version guard checks, and Go version derived from Rancher’sgo.modin the workflow). - Extended Renovate configuration to include
release/v0.15.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/workflows/release-against-rancher.yml | Switches to computed versions and uses Rancher’s go.mod for Go setup |
| .github/scripts/release-against-rancher.sh | Adds guard logic and refactors API bump behavior |
| .github/scripts/compute-rancher-versions.sh | New script to compute Fleet/Chart versions and target Rancher branch |
| .github/renovate.json | Adds release/v0.15 branch support and matching Renovate preset |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
thardeck
force-pushed
the
small_improvements
branch
from
af949d5 to
5912839
Compare
thardeck
force-pushed
the
small_improvements
branch
3 times, most recently
from
3a7d70e to
dbad465
Compare
Compute Fleet and Rancher versions, target branch, and API bump flag from rancher/charts dev branch versions via GitHub API. User selects only the Fleet release branch from a dropdown; removes four text inputs. - compute-rancher-versions.sh: derives new_fleet, new_chart, rancher_ref (selected Rancher release branch or main on 404) - release-against-rancher.sh: remove Dockerfile fallback (unused); add build.yaml existence and field guard; detect API bump from presence of pkg/apis/v<version> tag in the fleet repo and derive the commit from that same tag; use explicit go.mod/go.sum paths instead of wildcards - release-against-rancher.yml: single fleet_branch choice input, compute all versions, check out rancher at computed ref
thardeck
force-pushed
the
small_improvements
branch
from
dbad465 to
cd8f469
Compare
to prevent issues not bumping the API by accident.
| new_chart="${latest_chart%%+*}" | ||
|
|
||
| # Target the Rancher release branch when it exists; fall back to main. | ||
| rancher_ref="release/v2.${rancher_minor}" |
There was a problem hiding this comment.
I know we are far away but given this is hardcoded maybe add a note to be changed once we are in 3.x versioin?
There was a problem hiding this comment.
Good point, but where should I add it?
I guess when we switch to Rancher 3.x or Fleet 1.x we will have quite some places to adapt.
The calculation is at the moment Minor Fleet Version - 1 = Rancher Minor Version - that als would most likely not work anymore in both cases.
Trying to cover a wider variety of future cases would make the script significant more complicated I think, and there still can be changes which require us to fix things, like branch or repo changes and so on.
But the good thing is that we can not really break something here, worst case we'll get a weird pull request that we can close.
There was a problem hiding this comment.
I have added a comment. The drop-down list for the workflow is static, that we have to change every ~4 month (for every new Fleet minor release).
But since we manually have to branch it off anyway, I thought it is ok in combination with the convenience and higher reliability that the person releasing does not have to enter an exact or minor Fleet version themselves.
sbulage
left a comment
sbulage
left a comment
There was a problem hiding this comment.
LGTM from my side 👍 but some comments from @mmartin24 to consider.
|
|
||
| # Chart directory names follow the pattern <chart-version>+up<fleet-version>, | ||
| # e.g. 110.0.1+up0.15.1. | ||
| new_fleet="${latest_chart##*+up}" |
There was a problem hiding this comment.
This is a set of existing Fleet and chart versions, isn't it? Wouldn't we then overwrite an existing chart?
Reduces the "release Fleet against rancher/rancher" workflow to a single dropdown input by computing Fleet/chart versions and the Rancher target branch from the
rancher/chartsdev branch via the GitHub API, removing the need to look up four values manually.compute-rancher-versions.sh: new script that derivesnew_fleet,new_chart, andrancher_reffrom the latest chart directory in thedev-v2.Xbranch ofrancher/charts; falls back tomainwhen the Rancher release branch does not exist yetrelease-against-rancher.sh: removes unused Dockerfile fallback; adds explicitbuild.yamlguard; detects whether to bump the Fleet API by checking for apkg/apis/v<version>tag in the fleet repo and derives the commit hash from that same tag, avoiding a mismatch with the rootv<version>tag; uses explicitgo.mod/go.sumpaths instead of wildcards; errors out when the target or a newer version is already present inbuild.yamlrelease-against-rancher.yml: replaces four manual text inputs with a singlefleet_branchchoice input; all other values flow from the compute stepSuccessful run