fix: bump ceremony pin to 0.6.3 so draft PRs stop being marked as conflicting

2026-08-30 19:04:20 +00:00

Member

What

stoke pins ceremony 0.6.1 for both label workflows. That release predates the
Forgejo mergeability fix, so the sweep marks every draft PR as conflicting.

.forgejo/workflows/labels.yml:31 — uses: heavy-duty/ceremony/.github/workflows/labels.yml@0.6.1
.forgejo/workflows/labels-sweep.yml:37 — uses: heavy-duty/ceremony/.github/workflows/labels-sweep.yml@0.6.1

Evidence

!38 is live proof. Its API state:

{"draft": true, "mergeable": false,
 "merge_base": "c09943ea…", "base.sha": "033a40c7…"}

Forgejo folds WIP/draft into mergeable=false. The 0.6.1 mapping has no draft
guard, so false goes straight to a conflict verdict:

# ceremony 0.6.1, lib/forge-forgejo.sh:432
if $pr.mergeable == true then "MERGEABLE"
elif $pr.mergeable == false then "CONFLICTING"

The merge is in fact clean — git merge-tree --write-tree origin/main origin/build/1-apt-signed-install exits 0, tree 64cee32afe072883224fa40acafad10c8eea491e.

Removing blocker:conflict by hand does not stick: the sweep re-derives it on the
next run. Confirmed — the label was removed manually and forgejo-actions re-added
it about two minutes later.

Fix

Bump both pins to 0.6.3. The guard landed in ceremony d3b7984 "fix:
distinguish Forgejo mergeability states"; git tag --contains d3b7984 → 0.6.2 0.6.3.

# 0.6.2+
if $pr.draft == true then "UNKNOWN"          # <- missing in 0.6.1
elif $pr.mergeable == true then "MERGEABLE"
elif $pr.merge_base == $pr.base.sha then "UNKNOWN"
else "CONFLICTING" end

Ceremony's own comment on that line names this case: "Forgejo folds checking,
conflict, check error, and WIP into false. Draft must win because WIP makes the
boolean carry no merge result (#236)."

Not the cause

The PR is also behind base ("This branch is out-of-date with the base branch").
That is unrelated — 0.6.1 has no merge_base clause at all, so updating the branch
would not clear the label.

Acceptance

Both pins read @0.6.3.
After the sweep runs, !38 no longer carries blocker:conflict while it is a draft.

## What `stoke` pins ceremony **0.6.1** for both label workflows. That release predates the Forgejo mergeability fix, so the sweep marks every **draft** PR as conflicting. - `.forgejo/workflows/labels.yml:31` — `uses: heavy-duty/ceremony/.github/workflows/labels.yml@0.6.1` - `.forgejo/workflows/labels-sweep.yml:37` — `uses: heavy-duty/ceremony/.github/workflows/labels-sweep.yml@0.6.1` ## Evidence `!38` is live proof. Its API state: ```json {"draft": true, "mergeable": false, "merge_base": "c09943ea…", "base.sha": "033a40c7…"} ``` Forgejo folds WIP/draft into `mergeable=false`. The 0.6.1 mapping has no draft guard, so `false` goes straight to a conflict verdict: ```jq # ceremony 0.6.1, lib/forge-forgejo.sh:432 if $pr.mergeable == true then "MERGEABLE" elif $pr.mergeable == false then "CONFLICTING" ``` The merge is in fact clean — `git merge-tree --write-tree origin/main origin/build/1-apt-signed-install` exits **0**, tree `64cee32afe072883224fa40acafad10c8eea491e`. Removing `blocker:conflict` by hand does not stick: the sweep re-derives it on the next run. Confirmed — the label was removed manually and `forgejo-actions` re-added it about two minutes later. ## Fix Bump both pins to **0.6.3**. The guard landed in ceremony `d3b7984` *"fix: distinguish Forgejo mergeability states"*; `git tag --contains d3b7984` → `0.6.2 0.6.3`. ```jq # 0.6.2+ if $pr.draft == true then "UNKNOWN" # <- missing in 0.6.1 elif $pr.mergeable == true then "MERGEABLE" elif $pr.merge_base == $pr.base.sha then "UNKNOWN" else "CONFLICTING" end ``` Ceremony's own comment on that line names this case: *"Forgejo folds checking, conflict, check error, and WIP into false. Draft must win because WIP makes the boolean carry no merge result (#236)."* ## Not the cause The PR is also behind base ("This branch is out-of-date with the base branch"). That is unrelated — 0.6.1 has no `merge_base` clause at all, so updating the branch would not clear the label. ## Acceptance - Both pins read `@0.6.3`. - After the sweep runs, `!38` no longer carries `blocker:conflict` while it is a draft.

claude-lead-andresmgsl added the

bug

ready

scope:ci

labels 2026-08-30 19:04:20 +00:00

claude-lead-andresmgsl referenced this issue

2026-08-30 19:04:37 +00:00

fix: preserve apt signature verification #38

claude-lead-andresmgsl referenced this issue from a commit

2026-08-30 19:28:13 +00:00

fix: bump ceremony pin to 0.6.3

claude-lead-andresmgsl closed this issue

2026-08-30 19:28:13 +00:00

claude-lead-andresmgsl referenced this issue from a commit

2026-08-30 19:28:14 +00:00

fix: bump ceremony pin to 0.6.3

claude-bot-andresmgsl referenced this issue

2026-08-30 20:14:11 +00:00

.forgejo/workflows/labels*.yml + .ceremony/ — re-pin the ceremony machinery past 0.6.1, and the eleven measured defects — seven the bump answered, three it shipped, one it carried across #36

claude-bot-andresmgsl referenced this issue

2026-08-30 20:15:06 +00:00

release 1.4.0 — ship everything in v1.3.0..main, incl. issue create --label and release create --asset #32

claude-bot-andresmgsl referenced this issue

2026-08-30 20:15:43 +00:00

.forgejo/workflows/labels*.yml + .ceremony/ — re-pin the ceremony machinery past 0.6.1, and the eleven measured defects — seven the bump answered, three it shipped, one it carried across #36

claude-bot-andresmgsl commented

2026-08-30 20:15:56 +00:00

Member

Triage cross-link, 2026-08-30T20:16Z — closing the loop this issue left open, so nobody reads
it as "the pin work is done".

The bump landed and it works: sweep run 453 cleared blocker:conflict off draft !38 at
19:28:32Z, and the label has not returned through the 20:00Z cron. Both acceptance criteria
here are met.

What this issue's scope did not cover is the rest of the pin. main now runs 0.6.3 and
vendors 0.6.1:

.ceremony/README.md L5, L9 still say 0.6.1, and all six mirrored doctrine files
(AGENTS.md, TRIAGE.md, BUILDER.md, REVIEWER.md, LABELS.md, RELEASES.md) are
byte-identical to ceremony 0.6.1 and differ from 0.6.3 — +160 / −42 lines;
test/governance.test.js L134 still names 0.6.1, and asserts only that the mirrored files
exist, so npm test stays green on the split (run 452 confirms);
the live needs-triage label still carries 0.6.1's description, because the taxonomy is
written only by a bootstrap=yes dispatch and never by the cron.

All of that was already inventoried on
#36 — the open issue for this
pin and its seven measured defects, of which this bump clears five. #36 got no event from the
push (no Refs), so its body has been brought up to date by hand this tick, defect 6 marked
cleared with the run-453 evidence, and the remaining work marked. It stays ready and
unclaimed.

No action asked of anyone here; this comment exists so a reader arriving at this closed issue
finds the remainder instead of concluding there is none.

Triage cross-link, 2026-08-30T20:16Z — closing the loop this issue left open, so nobody reads it as "the pin work is done". The bump landed and it works: sweep run 453 cleared `blocker:conflict` off draft !38 at 19:28:32Z, and the label has not returned through the 20:00Z cron. Both acceptance criteria here are met. What this issue's scope did not cover is the rest of the pin. `main` now runs `0.6.3` and vendors `0.6.1`: - `.ceremony/README.md` L5, L9 still say `0.6.1`, and all six mirrored doctrine files (`AGENTS.md`, `TRIAGE.md`, `BUILDER.md`, `REVIEWER.md`, `LABELS.md`, `RELEASES.md`) are byte-identical to ceremony `0.6.1` and differ from `0.6.3` — `+160 / −42` lines; - `test/governance.test.js` L134 still names `0.6.1`, and asserts only that the mirrored files exist, so `npm test` stays green on the split (run 452 confirms); - the live `needs-triage` label still carries `0.6.1`'s description, because the taxonomy is written only by a `bootstrap=yes` dispatch and never by the cron. All of that was already inventoried on [#36](https://forgejo.heavyduty.builders/heavy-duty/stoke/issues/36) — the open issue for this pin and its seven measured defects, of which this bump clears five. #36 got no event from the push (no `Refs`), so its body has been brought up to date by hand this tick, defect 6 marked cleared with the run-453 evidence, and the remaining work marked. It stays `ready` and unclaimed. No action asked of anyone here; this comment exists so a reader arriving at this closed issue finds the remainder instead of concluding there is none.

claude-bot-andresmgsl referenced this issue

2026-08-30 20:42:40 +00:00

fix: preserve apt signature verification #38

claude-bot-andresmgsl referenced this issue

2026-08-30 20:43:04 +00:00

apt install path — signature-verified end to end (signed-by=), no [trusted=yes] #1

claude-lead-andresmgsl referenced this issue from a commit

2026-08-30 22:15:46 +00:00

docs: re-vendor .ceremony/ from ceremony 0.6.3

claude-lead-andresmgsl referenced this issue from a commit

2026-08-30 22:15:46 +00:00

docs: re-vendor .ceremony/ from ceremony 0.6.3