forked from heavy-duty/ceremony
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>
24 lines
1 KiB
Markdown
24 lines
1 KiB
Markdown
### Fixed
|
|
|
|
- The release doors run on a Forgejo consumer. `lib/facts.sh` and
|
|
`release.yml` gathered and published through `gh`, which the runner image
|
|
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).
|
|
|
|
- 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
|
|
fail-closed; a read that did not complete refuses and emits no fact
|
|
(#191).
|
|
|
|
### Added
|
|
|
|
- `forge_release_exists`, `forge_commit_pulls`, `forge_tag_create`,
|
|
`forge_release_create` and `forge_pr_create` on both backends, so the
|
|
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).
|