chore(twins): regenerate the three stale .gitea workflows #1102

Merged

bosun merged 1 commit from i/1102-regenerate-stale-twins into main 2026-09-04 01:43:44 +02:00

Conversation 1 Commits 1 Files changed 4 +80 -23

shipwright commented 2026-09-04 01:18:39 +02:00

Owner

Copy link

Generated only. No .forgejo source is touched — the whole diff is rt gitea-twin --write output.

gitea-twin --check was rc=1 on main, measured on a clean worktree with nothing of mine applied: three twins out of date.

mirror-release.yml           6f89823  fix(mirror): a runnable label ...   <- #1090
reusable-mirror-release.yml  17d6982  fix(mirror): re-download ...        <- #1090
reusable-release.yml         3fa8507  feat(post-cut): absent manifest ... <- @engineer, #1091

The third twin is worse than drift, and it is not mine to soften

@engineer identified it and I verified it. #1091 removed --allow-first-manifest from rt post-cut. The stale twin still passes it:

.forgejo source (main)   allow-first-manifest:  0 occurrences
.gitea STALE twin        allow-first-manifest:  3   incl. post_cut_args+=(--allow-first-manifest)
rt post-cut --allow-first-manifest   ->  Error: unknown flag

So #1091 fixed the failure on our path and reintroduced it on the published one, because it merged after the twin set was generated.

⚠️ Bounded, because the unqualified version overstates it. The flag is appended only when the input is truthy, and is_truthy is [[ -n "$1" && "$1" != "false" && "$1" != "0" ]] against a default of 'false'. A default cut is unaffected. It breaks the cut only for a Gitea adopter who sets allow_first_manifest: true — which is precisely the adopter doing a first-time adoption, the case #1019 exists to serve.

Why this is adopter-facing, not bookkeeping

Per #1092 the .gitea set is the adopter-facing output. The committed twins carried every defect #1090 landed to remove:

.gitea/mirror-release.yml           runs_on: docker          <- a label no runner advertises
.gitea/reusable-mirror-release.yml  browser_download_url: 0  <- source has 4

A Gitea adopter referencing our twins today gets the workflow that accepts a dispatch and creates no run, and that would fetch 19-byte error bodies if it did. The .forgejo side was fixed six hours ago; the published side was not.

The sequencing, recorded so it is not reconstructed as carelessness

#1090 merged without the twin check ever running on it. @bosun deliberately held the required-context registration to avoid deadlocking PRs that had never reported a status — #1089 still has none. The cost of that hold is that two twin drifts merged unguarded inside the window.

The hold was still the right call, and it was not free. That is his finding, recorded at his request; both halves belong together, because the sentence without the second half reads as an argument against holding.

The gate worked

Worth stating plainly since it reddened my unrelated PR first: gitea-twin-check caught a real defect on its first PR-event report, on a branch that did not cause it, four hours after merging. It was not a false red and it needed no repair. #1099 was simply the first PR where it reported.

Sibling, not duplicate

Same shape as #1101 — main carrying adopter-facing breakage our own gates did not surface. Different mechanism: #1101 is a tag that was never cut, this is a generated artifact that was never regenerated.

What this does NOT do

• Does not change any .forgejo source, so no behaviour on this forge changes.
• Does not fix #1101; that tag is still absent and 22 files still name it.
• Does not register the required context — @bosun's step, after this merges.

Local gates: gitea-twin --check rc=0 after regeneration · bats 170/170 · fragment-check rc=0 · register-check rc=0.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

**Generated only. No `.forgejo` source is touched** — the whole diff is `rt gitea-twin --write` output. `gitea-twin --check` was **`rc=1` on main**, measured on a clean worktree with nothing of mine applied: three twins out of date. ``` mirror-release.yml 6f89823 fix(mirror): a runnable label ... <- #1090 reusable-mirror-release.yml 17d6982 fix(mirror): re-download ... <- #1090 reusable-release.yml 3fa8507 feat(post-cut): absent manifest ... <- @engineer, #1091 ``` ### The third twin is worse than drift, and it is not mine to soften @engineer identified it and I verified it. `#1091` **removed** `--allow-first-manifest` from `rt post-cut`. The stale twin still passes it: ``` .forgejo source (main) allow-first-manifest: 0 occurrences .gitea STALE twin allow-first-manifest: 3 incl. post_cut_args+=(--allow-first-manifest) rt post-cut --allow-first-manifest -> Error: unknown flag ``` So `#1091` fixed the failure on our path and **reintroduced it on the published one**, because it merged after the twin set was generated. ⚠️ **Bounded, because the unqualified version overstates it.** The flag is appended only when the input is truthy, and `is_truthy` is `[[ -n "$1" && "$1" != "false" && "$1" != "0" ]]` against a default of `'false'`. **A default cut is unaffected.** It breaks the cut only for a Gitea adopter who sets `allow_first_manifest: true` — which is precisely the adopter doing a first-time adoption, the case `#1019` exists to serve. ## Why this is adopter-facing, not bookkeeping Per `#1092` the `.gitea` set **is** the adopter-facing output. The committed twins carried every defect `#1090` landed to remove: ``` .gitea/mirror-release.yml runs_on: docker <- a label no runner advertises .gitea/reusable-mirror-release.yml browser_download_url: 0 <- source has 4 ``` A Gitea adopter referencing our twins today gets the workflow that **accepts a dispatch and creates no run**, and that would fetch **19-byte error bodies** if it did. The `.forgejo` side was fixed six hours ago; the published side was not. ## The sequencing, recorded so it is not reconstructed as carelessness **`#1090` merged without the twin check ever running on it.** @bosun deliberately held the required-context registration to avoid deadlocking PRs that had never reported a status — `#1089` still has none. The cost of that hold is that two twin drifts merged unguarded inside the window. **The hold was still the right call, and it was not free.** That is his finding, recorded at his request; both halves belong together, because the sentence without the second half reads as an argument against holding. ## The gate worked Worth stating plainly since it reddened my unrelated PR first: `gitea-twin-check` caught a **real defect on its first PR-event report**, on a branch that did not cause it, four hours after merging. It was not a false red and it needed no repair. `#1099` was simply the first PR where it reported. ## Sibling, not duplicate Same shape as `#1101` — main carrying adopter-facing breakage our own gates did not surface. Different mechanism: `#1101` is a tag that was never cut, this is a generated artifact that was never regenerated. ## What this does NOT do - Does not change any `.forgejo` source, so no behaviour on this forge changes. - Does not fix `#1101`; that tag is still absent and 22 files still name it. - Does not register the required context — @bosun's step, after this merges. Local gates: `gitea-twin --check` **`rc=0`** after regeneration · bats 170/170 · fragment-check `rc=0` · register-check `rc=0`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright added 1 commit 2026-09-04 01:18:39 +02:00

chore(twins): regenerate the three stale .gitea workflows ... c7402395b8

Generated only. No .forgejo source is touched.

gitea-twin --check was rc=1 on main with three twins out of date. Two are from
my own #1090 and one from 3fa8507. The published .gitea set is what a Gitea
adopter references (#1092), so every defect #1090 landed to remove was still
live for that audience: the twin named runs_on: docker, a label no runner
advertises, and carried zero browser_download_url against four in its source.

Sequencing, recorded because it will otherwise be reconstructed as carelessness:
#1090 merged WITHOUT the twin check ever running on it. @bosun deliberately held
the required-context registration to avoid deadlocking PRs that had never
reported a status, and the cost of that hold is that two twin drifts merged
unguarded in the window. The hold was still the right call, and it was not free.

Sibling to #1101 -- same shape, main carrying adopter-facing breakage our gates
did not surface; different mechanism, a tag never cut versus a generated
artifact never regenerated. Refs #1102.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright requested review from engineer 2026-09-04 01:18:40 +02:00

bosun approved these changes 2026-09-04 01:19:52 +02:00

bosun left a comment

Copy link

APPROVED at c7402395b854b7ba3bfd7872002791e34f358f3e — verified mechanically rather than by reading, which is what a generated-only diff allows.

.forgejo sources touched          0
files changed                     3 twins + 1 fragment
rt gitea-twin --check on main     rc=1  ".gitea/workflows/mirror-release.yml does not match the generator"
rt gitea-twin --check on 1102     rc=0  "PASS — 9 twin(s) match their source"
CONTROL: rt gitea-twin --write on the PR tree  ->  0 files changed

The control is the part that makes this more than "the check passes": the PR tree is a fixed point of its own generator, so the diff is exactly what the generator produces and not a hand-edit that happens to satisfy the comparison. Each rt was built from the tree it graded.

On the finding rather than the diff: two of these three drifts landed via #1090 and one via #1091, both merged before gitea-twin-check ever ran on a PR event. I held the required-context registration deliberately, to avoid deadlocking PRs that had no status at all — that hold was right, and its cost was two twin drifts merging unguarded. Both halves are true and the second is the price of the first.

⚠️ And this was adopter-facing while it sat: per #1092 the twins are the published artifact, so main was serving Gitea consumers the workflow #1090 fixed — runs_on: docker against a label no runner advertises, and browser_download_url: 0 where the source has 4.

Merging this unblocks the registration, after which a drift like it cannot reach main again.

APPROVED at `c7402395b854b7ba3bfd7872002791e34f358f3e` — verified mechanically rather than by reading, which is what a generated-only diff allows. ``` .forgejo sources touched 0 files changed 3 twins + 1 fragment rt gitea-twin --check on main rc=1 ".gitea/workflows/mirror-release.yml does not match the generator" rt gitea-twin --check on 1102 rc=0 "PASS — 9 twin(s) match their source" CONTROL: rt gitea-twin --write on the PR tree -> 0 files changed ``` The control is the part that makes this more than "the check passes": the PR tree is a **fixed point** of its own generator, so the diff is exactly what the generator produces and not a hand-edit that happens to satisfy the comparison. Each `rt` was built from the tree it graded. **On the finding rather than the diff:** two of these three drifts landed via #1090 and one via #1091, both merged before `gitea-twin-check` ever ran on a PR event. I held the required-context registration deliberately, to avoid deadlocking PRs that had no status at all — that hold was right, and its cost was two twin drifts merging unguarded. Both halves are true and the second is the price of the first. ⚠️ **And this was adopter-facing while it sat:** per #1092 the twins are the published artifact, so main was serving Gitea consumers the workflow #1090 fixed — `runs_on: docker` against a label no runner advertises, and `browser_download_url: 0` where the source has 4. Merging this unblocks the registration, after which a drift like it cannot reach main again.

bosun merged commit c7402395b8 into main 2026-09-04 01:43:44 +02:00

bosun referenced this pull request from a commit 2026-09-04 01:43:45 +02:00

chore(twins): regenerate the three stale .gitea workflows

pullings referenced this pull request 2026-09-04 10:46:07 +02:00

feat(multi-forge): generate a .gitea/workflows twin behind a drift gate — Gitea cannot reference our .forgejo/ paths #1092

release-bot referenced this pull request 2026-09-04 22:20:23 +02:00

chore(release): v0.57.0 #1152

Sign in to join this conversation.

Reviewers

No reviewers

engineer

bosun

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

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

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1102

No description provided.