bug(release-decide): Layer 2 must use head.label not head.ref — Forgejo replaces head.ref with refs/pull/N/head on auto-delete-branch merge #92
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit#92
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Symptom
When operator merged the v0.6.0 rolling PR #90, the cut workflow fired but emitted
mode=noopinstead ofmode=cut. The first task ran in 4s (decide+act) + the second in 0s (release job) + manifest stayed at v0.5.0 + no v0.6.0 draft was created.Re-dispatching via
workflow_dispatchproduced the samemode=noopresult. Both runs identical:act on decision: noop: no_release_relevant_content — nothing to do.Root cause
Verified at source: Forgejo's
default_delete_branch_after_merge: true(the toolkit repo's setting) deletes the head branch when a PR merges. After deletion, the PR'shead.refis replaced from the original branch name (release-prep/rolling) to the pull-request internal ref (refs/pull/90/head).The PR API shows for #90 (verified post-merge):
My Layer 2 check (
release-decide.sh:226) does[[ "$head_ref" == "$ROLLING_BRANCH_NAME" ]]→ FALSE becausehead.refis nowrefs/pull/90/head. Layer 2 returnsfail→ fall-through to mode=update → bump determination finds zero release-relevant content (fragment already consumed in prep commit; cc-commits arechore(...)+fold(...)+fix+feat:non-standard prefixes) → mode=noop withreason=no_release_relevant_content.Fix
Use
head.label(orhead.label.split(":")[-1]) instead ofhead.reffor the branch-source check.head.labelis the canonical "owner:branch-name" form that PRESERVES across the branch-lifecycle.Concretely:
Apply the same fix to
forgejo_find_pr_by_merge_sha's downstream consumers (if any).Also affects #87 stale rolling PR cleanup
The new #87 cleanup queries OPEN PRs with
head.ref == "release-prep/rolling"— but for a stale rolling PR that was opened pre-fall-through, the head.ref should still berelease-prep/rolling(no merge yet → no branch deletion). So #87 is likely fine. But worth dual-checking after the Layer 2 fix lands — the rolling branch is the STABLE rolling identity; if it gets recreated after the cleanup deletion-on-merge, the substrate behavior could shift.Same lesson class as AGENTS.md §8 4th instance
I assumed
head.refpreserves across the branch lifecycle without verifying. Surveyor's source-grounded-vs-invented discipline applies AGAIN — 5th empirical instance of the §8 axis. Banking as a v0.5.2 AGENTS.md update to surface n=5 promoting the axis to a named project pattern per the empirical-promotion criterion.Recovery (already done for v0.6.0)
scripts/draft-release.sh --version 0.6.0 --commit ba10f67c→ draft release id=125 createdd44546e)Refs
release-prep/rollingdirectly without exercising the post-merge branch-deletion case; v0.5.2 test should cover head.ref-replaced scenario)