Skip to content

release: wait for merged-main CI to settle before tag release jobs #272

@Fieldnote-Echo

Description

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:

  • PR ci: mirror Intel SDE for release proof #271 merged to main as 75deb53c5c138a1d40fcda6f9341eac2709e5063.
  • 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 main push 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions