Skip to content

docs(genie): replace the dead v4 release recovery section #82

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
automagik-genie wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs(genie): replace the dead v4 release recovery section #82

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 20 additions & 14 deletions genie/_internal/runbooks/release-pipeline.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,24 +17,30 @@ gh run view --log "$RUN_ID"

## Recovery

If build succeeded but sign-attest failed, dispatch the per-file escape hatch.
There is no per-file escape hatch. `sign-attest.yml` and `release-publish.yml` are `workflow_call`-only — they run as jobs inside one release attempt and cannot be dispatched with an external run id. As `release-publish.yml` puts it: "All artifacts are from one workflow run; there is no standalone dispatch or external run-id recovery path."

### Transient failure inside one release attempt

Re-run the failed jobs of that same run:

```bash
RUN_ID=12345 # paste the build-tarballs run id
gh workflow run sign-attest.yml \
--field version=4.260510.6 \
--field run_id="$RUN_ID"
gh run rerun <run-id> --failed
```

After sign-attest succeeds, dispatch publish with its run id.
Prefer re-running the whole run over a partial re-run. Every artifact's endorsement carries the signer run that produced it, and the stable security gate requires them all to agree; artifacts mixed across attempts fail the gate with `verified signer run disagreement`.

### A dev release whose tag is already pushed

It cannot be republished. `version.yml` derives a fresh build number from the existing `v5.<yymmdd>.*` tags, pushes the version commit and the new tag with one `git push --atomic`, and only calls `release.yml` after that push succeeds. A re-run re-derives against the tag that now exists, so the atomic push is rejected and the run stops at:

```bash
SIGN_RUN=12345 # paste the sign-attest run id
gh workflow run release-publish.yml \
--field version=4.260510.6 \
--field run_id="$SIGN_RUN" \
--field channel=stable \
--field draft=false
```
release-race.next-tag-pin-skipped.detected
```

The remedy is to land any commit on `dev` through a normal PR — the next green CI run allocates the next build number and publishes it. The orphan tag is already acknowledged by the Release Orphan Alert issue; do not try to re-dispatch that version.

### Stable

Stable is never auto-dispatched. After the promotion PR merges, `version.yml` pushes the fresh promotion tag and writes the `release.yml` inputs into the run summary (`version`, `channel: stable`, `source_sha`, `source_branch: main`, `source_ci_run_id`). A maintainer then opens **Actions → Release → Run workflow** on `main` and supplies them; manual dispatch offers `stable` as the only channel. A different maintainer must approve the protected `production` environment — the initiator cannot.

If the orchestrator never fires, check that `version.yml` dispatched it.
If the orchestrator never fires at all, check that `version.yml` reached its release job.