You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
v0.5.0 was moved to that commit and pushed immediately.
Release run 27874699968 started on tag v0.5.0 / 75deb53c5c138a1d40fcda6f9341eac2709e5063.
Job require full CI green for this commit failed.
Job prove AVX-512 coverage under Intel SDE was skipped because it depends on the guard.
Shortly afterward, direct API checks for the required main push workflows for the same SHA returned successful runs.
This means the release guard is effectively checking for already-indexed successful runs, not waiting for the merged-main checks to finish and become visible.
Why this matters
Release tags are allowed only after main is green. If a small release-workflow fix is merged and the release tag is moved promptly, the release workflow should wait for the required main push checks to settle instead of failing early. This creates noisy failed release runs and can leave a red check on the release tag even when main is otherwise healthy.
Desired behavior
Update .github/workflows/release.yml so the release path has a real front-door wait gate:
For the tag commit SHA, poll the required mainpush workflow runs until they are terminal or a bounded timeout is reached.
Required workflows should include the same set currently checked by require-ci-green: ci.yml, python.yml, fuzz.yml, codeql.yml, actionlint.yml, and zizmor.yml.
Treat queued / in_progress / not-yet-visible runs as pending, not failure.
Fail only after timeout or after a required workflow reaches an unacceptable terminal conclusion.
Ensure downstream release jobs, including AVX-512 proof, artifact construction, publish, and GitHub release creation, do not start until this gate succeeds.
Emit clear diagnostics showing which workflow is pending, missing, failed, or successful.
Acceptance criteria
A tag pushed immediately after a PR merge waits for the merged-main checks rather than failing the guard early.
The guard still fails closed if any required workflow fails or never appears before timeout.
The release workflow remains tag-only and preserves the existing environment/publish protections.
Add or update release invariant coverage if practical so this wait/poll behavior does not regress.
Problem
The tag release workflow can race the main-branch CI checks after a release-fix PR is merged and the release tag is moved immediately afterward.
Concrete case from the v0.5.0 retag:
75deb53c5c138a1d40fcda6f9341eac2709e5063.v0.5.0was moved to that commit and pushed immediately.27874699968started on tagv0.5.0/75deb53c5c138a1d40fcda6f9341eac2709e5063.require full CI green for this commitfailed.prove AVX-512 coverage under Intel SDEwas skipped because it depends on the guard.This means the release guard is effectively checking for already-indexed successful runs, not waiting for the merged-main checks to finish and become visible.
Why this matters
Release tags are allowed only after main is green. If a small release-workflow fix is merged and the release tag is moved promptly, the release workflow should wait for the required
mainpush checks to settle instead of failing early. This creates noisy failed release runs and can leave a red check on the release tag even when main is otherwise healthy.Desired behavior
Update
.github/workflows/release.ymlso the release path has a real front-door wait gate:mainpushworkflow runs until they are terminal or a bounded timeout is reached.require-ci-green:ci.yml,python.yml,fuzz.yml,codeql.yml,actionlint.yml, andzizmor.yml.queued/in_progress/ not-yet-visible runs as pending, not failure.Acceptance criteria