fix(release): dispatch recovery from the existing release tag - #15
Merged
Conversation
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.
Validate now dispatches stage 3 from the most durable exact release source it has: when the
<version>tag already exists and points at the validated release commit (the forensics step already asserts consistency), it dispatches on the tag and skips creating therelease-run/<version>recovery branch; the branch is only created - as before - when no tag exists yet (fresh merge, or recovery of a release that failed before tagging). Stage 3 acceptsrefs/tags/<version>as an exact source since its introduction, so no consumer change is needed.Besides removing an unnecessary write from every re-validation of an already-tagged release, this fixes dispatch recovery on PodNotes, found while E2E-testing #9: its Actions
GITHUB_TOKENdeterministically gets403 Resource not accessible by integrationfromPOST /git/refswhen the target is an older commit whose.github/workflowscontent differs from the branch head (verified with a minimal probe workflow: createRef at head succeeds, includingrelease-run/*names; createRef at the prior release commit fails; the identical probe pattern succeeds on MetaEdit, so GitHub applies this inconsistently per repo). With this change the quirk can only matter for recovering a release that failed before its tag was created on such a repo - webhook redelivery, documented in the README recovery section, covers that residual case.Refs #9