fix: harden major-tag update (release: published)#135
Conversation
The release: published event is suppressed by GITHUB_TOKEN anti-recursion when a release is published by automation, which left v8 stuck on v8.3.7 after the v8.3.8 release (build-image.yaml@v8 then lacked the timeoutMinutes input, breaking kubernetes.yaml@v8.3.8 consumers). Trigger on the semver tag push instead (created only on publish, never on drafts), derive the version from the pushed ref, and add a workflow_dispatch recovery lever to realign the major tag manually.
There was a problem hiding this comment.
Pull request overview
This PR updates the “Update major tag” GitHub Actions workflow so the major tag (e.g. v8) is kept aligned with the latest patch/minor release tag (e.g. v8.3.8), avoiding the release: published event suppression that previously caused v8 to lag behind and break downstream reusable workflow references.
Changes:
- Switch workflow trigger from
release: publishedtopushon semver tags, plus add a manualworkflow_dispatchrecovery input. - Derive the version directly from
github.ref_name(or dispatch input) instead ofgit describe. - Update the major tag via
git tag -fand a force-push, making the operation idempotent.
Address review feedback: - on.push.tags uses glob syntax, not regex; v[0-9]+.[0-9]+.[0-9]+ required a literal '+' and would never match v8.3.8. Use v[0-9]*.[0-9]*.[0-9]* and enforce the exact vX.Y.Z shape in the script (also skips pre-releases). - push fires on tag deletion too; add a job-level guard so it only runs on tag creation or manual dispatch.
There was a problem hiding this comment.
That event is suppressed by GitHub's GITHUB_TOKEN anti-recursion rule when a release is published by automation, so the workflow never ran for the v8.3.8
I think we should focus on fixing this instead, releases are supposed to be published manually only. We should stick to the release trigger as a more reliable and clear option rather than getting back to tag push trigger.
Keep release: published (releases are created manually by a human, so the GITHUB_TOKEN suppression does not apply), but harden the weak parts: - take the version from github.event.release.tag_name instead of fragile git describe topology guessing - enforce strict vX.Y.Z semver and skip pre-releases - add workflow_dispatch recovery lever to realign the major tag by hand - idempotent git tag -f + force-push instead of delete-then-recreate
jmpalomares
changed the title
|
@kpplis @jmpalomares I added the tag push with a regex that should help to trigger |
Problem
The
v8major tag silently fell a release behind after v8.3.8.ci.update-major-version-tag.yamltriggerson: release: published, but that event is suppressed when the release is published by the defaultGITHUB_TOKEN(GitHub anti-recursion). The v8.3.8 release was published via automation, so the workflow never ran — leavingv8pinned to v8.3.7's commit.Because PR #127 added the
timeoutMinutesinput tobuild-image.yamlin v8.3.8,kubernetes.yaml@v8.3.8forwardingtimeoutMinutestobuild-image.yaml@v8(still v8.3.7, no such input) failed validation for every consumer:(
v8has already been manually realigned to v8.3.8 to unblock consumers; this PR prevents recurrence.)Approach
Releases are created/published manually by a human, so the
GITHUB_TOKENsuppression does not apply to the normal flow — a person publishing in the UI fires the event reliably. We therefore keeprelease: published(semantically correct, won't fire on stray tag pushes) and harden the weak parts instead.Changes
github.event.release.tag_nameinstead of the fragilegit describe --tags --abbrev=0topology guess.vX.Y.Zsemver and skip pre-releases (github.event.release.prerelease).workflow_dispatchinput to realign the major tag by hand if an event is ever missed (the v8.3.8 recovery path).git tag -f+ force-push instead of delete-then-recreate.Operational note
Publish releases as a human (or PAT), never via the default
GITHUB_TOKEN— otherwise therelease: publishedevent is suppressed andv8lags behind again.