Always dispatch Deploy from Release - #3
Merged
Merged
Conversation
Releases have been tagging correctly and never deploying. v0.2.1 was tagged, Release reported success, and the Deploy workflow had zero runs — the site sat on an old build while every signal said green. The cause was a conditional I added to support an optional PAT. Release only started Deploy when RELEASE_TOKEN was absent, on the assumption that a PAT-pushed tag would trigger `on: push: tags` natively. Once a PAT was configured that assumption silently took over, and the native trigger did not fire. Release now dispatches Deploy unconditionally. Whether a tag push triggers a workflow depends on how GitHub attributes the pushing credential, and that is not something a release pipeline should depend on. Deploy is idempotent — it builds and uploads the same tag — so a duplicate run is harmless, whereas a missed one is invisible, which is precisely the failure this had. The wider lesson, recorded in CONTRIBUTING: a deploy that silently does not happen is indistinguishable from one that succeeded. Prefer the deterministic path even when the implicit one should work.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The bug
v0.2.1tagged correctly. Release reported success. The Deploy workflow had zero runs. The site sat on an old build while every signal said green — which is why you saw no change on devtools.fadeltd.dev.Nothing failed to upload. Nothing was ever uploaded, because Deploy never started.
Cause
A conditional I added to support the optional PAT:
The reasoning was: without a PAT, dispatch Deploy explicitly; with one, the tag push triggers it natively. Once
RELEASE_TOKENwas configured,HAS_PATbecametrue, that step was skipped by design, and the native tag trigger did not fire.I verified each link in the chain before concluding: Deploy is registered and active,
v0.2.1exists on the remote, anddeploy.ymlis present at that tag (HTTP 200). All the preconditions were satisfied; the event simply never produced a run.Fix
Release now dispatches Deploy unconditionally. Whether a tag push triggers a workflow depends on how GitHub attributes the pushing credential, and a release pipeline should not depend on that. Deploy is idempotent — same tag, same build — so a duplicate run is harmless, whereas a missed one is invisible.
deploy.ymlkeepson: push: tagsso a hand-pushed tag still deploys.Already done manually
I dispatched Deploy for
v0.2.1to unblock you. It passed every step including the live smoke check, sodeploy.ymlitself is now validated end to end. The site is current:/id-genserves ID Generator — devtools, the sitemap lists 7 URLs, and the GitHub link and collapsible sidebar are in the deployed bundle.My error, twice
This is the second bug I have shipped in this release automation — the first was checking out the triggering sha instead of the branch tip. Both were in the paths that only execute on a real release, which is exactly where I had no coverage. The dual-path PAT logic was the root of this one, and I had flagged it as a liability before it broke without removing it. It is gone now.
Merging this cuts v0.2.2
Dry run:
[Unreleased]has only### Fixed→ patch →v0.2.2. That merge is also the first genuine end-to-end test of the corrected chain: merge → tag → dispatch → deploy.Verification
release.ymlparses; zeroHAS_PATreferences remain.