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
{{ message }}
Repository navigation
emrg: the release tag has no maintained push path when git-over-https is down #2795
Release stage 2 — publishing the annotated tag — has no maintained path when git-over-https is
unreachable. Measured on this host while releasing v0.3.47: github.com over the configured proxy
refuses the connection, so git push origin v0.3.47 cannot run, while api.github.com answers
normally.
scripts/push-branch-from-api.py exists precisely to make the push direction a maintained tool
instead of a script re-derived from notes each time, and its docstring says so. But it pushes refs/heads only. Publishing the tag therefore took a throwaway script written for the occasion
and deleted afterwards — the exact flow the branch counterpart was created to end.
Why it matters
The tag push is the only trigger of build-release.yml, so a release cannot finish without it.
Under an outage every release re-derives the same ~40 lines from memory, and nothing tests them:
the branch code has 14 hermetic tests with a fake API, the tag code has none because it has no
home in the repository.
What the fix must satisfy
A --tag mode on scripts/push-branch-from-api.py, alongside the existing --branch mode:
Exactly one of --branch / --tag per invocation; neither or both is a usage error.
Refuse a lightweight tag before any network call — the release pipeline's own verify-tag
job requires an annotated tag, so a lightweight one would fail after the work was spent.
Create the annotated tag object with POST /git/tags, preserving the tagger's own instant and
offset from the local tag object rather than stamping "now".
Create refs/tags/<name> with POST /git/refs pointing at that tag object.
Never force-move an existing tag: an existing ref at a different object is refused, and an
existing ref already at the same commit is a no-op, not an error.
Read the ref back and fail if it does not answer the object that was created.
Be covered by hermetic tests in tests/test_push_branch_from_api.py with the same fake-API
shape the branch path already uses — order of the two calls, the offset carried into the tagger
date, the lightweight refusal, and the no-force rule.
Activity
argszero commentedon Nov 10, 2026
Handled by #2796