ci(release): move the failed-run retry where the rerun API accepts it - #1322
Open
FerroxLabs wants to merge 1 commit into
Open
FerroxLabs wants to merge 1 commit into
FerroxLabs wants to merge 1 commit into
Conversation
The auto-retry job inside Build and Release could never have worked. It slept
five minutes and then POSTed .../actions/runs/<id>/rerun for its OWN run id,
but it was a job of that run, so the run was necessarily still in progress:
403 {"message": "This workflow is already running"}
It was skipped on every green run and on every dev build, so it first executed
on v0.12.14 and failed exactly as written, five minutes after a transient Azure
signing crash had already cost a twenty-minute build. The same class as the four
acceptance defects that burned nine version numbers: code no run had reached.
Replaced with a workflow_run-triggered workflow, which fires only after the run
has finished and is therefore the one moment the rerun API will accept the call.
Verified by hand on v0.12.14: once the run reached completed, rerun-failed-jobs
was accepted, produced attempt 2, and rebuilt only the one failed target while
the five green builds kept their artifacts. That is why this uses
rerun-failed-jobs rather than a full rerun.
Loop safety is the run_attempt == 1 guard: a run this retries becomes attempt 2
and can never trigger it again. head_branch reaches the shell through env rather
than template interpolation, so a crafted branch name cannot inject.
github-actions
Bot
added
area:packaging
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 auto-retry job inside Build and Release could never have worked. It slept five minutes and then POSTed .../actions/runs//rerun for its OWN run id, but it was a job of that run, so the run was necessarily still in progress:
It was skipped on every green run and on every dev build, so it first executed on v0.12.14 and failed exactly as written, five minutes after a transient Azure signing crash had already cost a twenty-minute build. Same class as the four acceptance defects that burned nine version numbers: code no run had reached.
Replaced with a workflow_run-triggered workflow, which fires only after the run has finished and is therefore the one moment the rerun API will accept the call.
Verified by hand on v0.12.14: once the run reached completed, rerun-failed-jobs was accepted, produced attempt 2, and rebuilt only the one failed target while the five green builds kept their artifacts. That is why this uses rerun-failed-jobs rather than a full rerun.
Loop safety is the run_attempt == 1 guard: a run this retries becomes attempt 2 and can never trigger it again. head_branch reaches the shell through env rather than template interpolation, so a crafted branch name cannot inject.
Worth a careful read since it changes the release workflow. Nothing references the removed job.