codex-bot-andresmgsl/ceremony
1
0
Fork 0
forked from heavy-duty/ceremony
Code Pull requests Activity
ceremony/changelog.d/191.md

25 lines
1 KiB
Markdown
Raw Normal View History

fix(forge): the release doors speak the shim, and an unread fact refuses (#191) The 0.4.1 drill measured both doors dead on Forgejo. lib/facts.sh gathered `released` with `gh release view` and `labeled` with `gh api .../pulls`, and release.yml tagged and published with `gh` — none of which exist on the runner image. The merge door therefore read labeled=no for a correctly labeled, correctly merged ceremony PR and refused it as "a bare push"; the tag door cleared every gate and died at `gh release create`. Both are ported onto lib/forge.sh. Two asymmetries were measured against the live instance and its swagger rather than assumed: * GitHub serves an ARRAY of PRs at /commits/{sha}/pulls; Forgejo serves a single OBJECT at /commits/{sha}/pull and 404s on the plural. Both verbs emit the array shape, so facts.sh carries one jq expression. * GitHub creates a tag by POSTing to /git/refs; Forgejo serves that path GET-only and creates tags at /tags. A 1:1 port of the gh call would have 404'd forever. The behaviour change is the second half of the bug. Any failure used to become a definite `no`, which is safe for row 4 and catastrophic for row 5: it is how a missing binary became "this was not a release ceremony". Now a completed read that finds nothing is still `no` and still fail-closed, and a read that did not complete refuses and emits no fact at all. Four new cases in test/facts.test.sh cover exactly that, and a mutation back to the old fail-closed-on-error behaviour kills all four and nothing else. 1014 assertions, 22 suites, shellcheck and actionlint clean. Refs #191 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 11:31:06 +00:00
### Fixed
- The release doors run on a Forgejo consumer. `lib/facts.sh` and
`release.yml` gathered and published through `gh`, which the runner image
fix(forge): facts.sh must set REPO, and the fragment must fit the bound Two failures on !193's first run, both real and both caught by the guards that exist for them. release-exercise: `lib/forge-forgejo.sh: line 550: REPO: unbound variable`. The forgejo backend addresses the repository through REPO, which each reconciler sets for itself; the github backend reads GITHUB_REPOSITORY directly. facts.sh set neither, so every forgejo read refused — correctly, and with the new #191 diagnostic, which is how it was legible at all. The github-path suites could not have caught this: they never touch that backend. self-guards: changelog-armed measured a 404-character entry against the 300-character bound (#167). Split into three shorter entries in the same fragment, which is what the rule asks for. Refs #191 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 11:37:00 +00:00
does not ship, so the merge door read `labeled=no` for a correctly
labeled ceremony PR and the tag door died at the publish (#191).
fix(forge): the release doors speak the shim, and an unread fact refuses (#191) The 0.4.1 drill measured both doors dead on Forgejo. lib/facts.sh gathered `released` with `gh release view` and `labeled` with `gh api .../pulls`, and release.yml tagged and published with `gh` — none of which exist on the runner image. The merge door therefore read labeled=no for a correctly labeled, correctly merged ceremony PR and refused it as "a bare push"; the tag door cleared every gate and died at `gh release create`. Both are ported onto lib/forge.sh. Two asymmetries were measured against the live instance and its swagger rather than assumed: * GitHub serves an ARRAY of PRs at /commits/{sha}/pulls; Forgejo serves a single OBJECT at /commits/{sha}/pull and 404s on the plural. Both verbs emit the array shape, so facts.sh carries one jq expression. * GitHub creates a tag by POSTing to /git/refs; Forgejo serves that path GET-only and creates tags at /tags. A 1:1 port of the gh call would have 404'd forever. The behaviour change is the second half of the bug. Any failure used to become a definite `no`, which is safe for row 4 and catastrophic for row 5: it is how a missing binary became "this was not a release ceremony". Now a completed read that finds nothing is still `no` and still fail-closed, and a read that did not complete refuses and emits no fact at all. Four new cases in test/facts.test.sh cover exactly that, and a mutation back to the old fail-closed-on-error behaviour kills all four and nothing else. 1014 assertions, 22 suites, shellcheck and actionlint clean. Refs #191 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 11:31:06 +00:00
- A release fact that could not be read is no longer reported as a definite
`no`. A completed read finding no label is still `no` and still
fix(forge): facts.sh must set REPO, and the fragment must fit the bound Two failures on !193's first run, both real and both caught by the guards that exist for them. release-exercise: `lib/forge-forgejo.sh: line 550: REPO: unbound variable`. The forgejo backend addresses the repository through REPO, which each reconciler sets for itself; the github backend reads GITHUB_REPOSITORY directly. facts.sh set neither, so every forgejo read refused — correctly, and with the new #191 diagnostic, which is how it was legible at all. The github-path suites could not have caught this: they never touch that backend. self-guards: changelog-armed measured a 404-character entry against the 300-character bound (#167). Split into three shorter entries in the same fragment, which is what the rule asks for. Refs #191 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 11:37:00 +00:00
fail-closed; a read that did not complete refuses and emits no fact
(#191).
fix(forge): the release doors speak the shim, and an unread fact refuses (#191) The 0.4.1 drill measured both doors dead on Forgejo. lib/facts.sh gathered `released` with `gh release view` and `labeled` with `gh api .../pulls`, and release.yml tagged and published with `gh` — none of which exist on the runner image. The merge door therefore read labeled=no for a correctly labeled, correctly merged ceremony PR and refused it as "a bare push"; the tag door cleared every gate and died at `gh release create`. Both are ported onto lib/forge.sh. Two asymmetries were measured against the live instance and its swagger rather than assumed: * GitHub serves an ARRAY of PRs at /commits/{sha}/pulls; Forgejo serves a single OBJECT at /commits/{sha}/pull and 404s on the plural. Both verbs emit the array shape, so facts.sh carries one jq expression. * GitHub creates a tag by POSTing to /git/refs; Forgejo serves that path GET-only and creates tags at /tags. A 1:1 port of the gh call would have 404'd forever. The behaviour change is the second half of the bug. Any failure used to become a definite `no`, which is safe for row 4 and catastrophic for row 5: it is how a missing binary became "this was not a release ceremony". Now a completed read that finds nothing is still `no` and still fail-closed, and a read that did not complete refuses and emits no fact at all. Four new cases in test/facts.test.sh cover exactly that, and a mutation back to the old fail-closed-on-error behaviour kills all four and nothing else. 1014 assertions, 22 suites, shellcheck and actionlint clean. Refs #191 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 11:31:06 +00:00
### Added
- `forge_release_exists`, `forge_commit_pulls`, `forge_tag_create`,
`forge_release_create` and `forge_pr_create` on both backends, so the
fix(forge): facts.sh must set REPO, and the fragment must fit the bound Two failures on !193's first run, both real and both caught by the guards that exist for them. release-exercise: `lib/forge-forgejo.sh: line 550: REPO: unbound variable`. The forgejo backend addresses the repository through REPO, which each reconciler sets for itself; the github backend reads GITHUB_REPOSITORY directly. facts.sh set neither, so every forgejo read refused — correctly, and with the new #191 diagnostic, which is how it was legible at all. The github-path suites could not have caught this: they never touch that backend. self-guards: changelog-armed measured a 404-character entry against the 300-character bound (#167). Split into three shorter entries in the same fragment, which is what the rule asks for. Refs #191 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-04 11:37:00 +00:00
release path names no client (#191).
- The forgejo backend serves one PR object at `/commits/{sha}/pull` where
GitHub serves an array at `/pulls`; both verbs emit the array shape, so
the call site carries one expression (#191).
- Forgejo creates tags at `POST /tags` — it serves `/git/refs` GET-only,
so GitHub's ref-POST would have 404'd there forever (#191).
Copy permalink