feat(workflows): drop workflow_dispatch from publish trigger #35

Merged

ses merged 1 commit from feat/workflows-publish-trigger into main

2026-09-04 22:29:01 +00:00

ses commented

2026-09-04 22:27:45 +00:00

Owner

Summary

publish.yaml triggers on release: [published] only; workflow_dispatch removed.
derive-tag.sh simplified: FORGEJO_EVENT_RELEASE_TAG_NAME is the only source of the tag.
AGENTS.md trigger note and procedure step 2 rewritten to match.

Why

Symptom: the v0.5.1 release session shipped release: published + workflow_dispatch as the publish trigger. The dispatch arm was a workaround for a draft-first procedure that wasn't firing the workflow at the time, but on closer reading of the Forgejo v16.0 actions docs, release.published does fire for draft releases on this host ("published: the release was created"). The dispatch arm is no longer needed and adds two failure modes:
1. With ref/event_name claim rules loosened in the Authorized Integration to let workflow_dispatch mint publishable JWTs, any future workflow added to this repo can mint a publishable token. Retightening requires admin-UI access, not a PR.
2. Dispatch against a SHA ref bypasses the tag ref the procedure is built around.
Root cause: the v0.5.1 post-mortem attributed "draft didn't fire" to a trigger mismatch; the actual behaviour on v16.0 is that drafts do fire release.published. The post-mortem narrative is wrong about Issue 1; the trigger fix landed in f9bcfee is the real change, and workflow_dispatch was scaffolding around the misdiagnosis.
Policy: the release is created up-front via plugin tools, which fires release: published against the tag ref. No fallback path is required; if a future draft doesn't fire, the recovery is the documented delete-and-redo flow.
Alternatives rejected:
- push: tags: ['v*'] instead — re-introduces the pre-6d02892 coupling between git push vX.Y.Z and CI, and conflicts with the plugin-driven release flow in AGENTS.md.
- release: types: [created, published] — keeps the manual-fallback ergonomic of dispatch but at the cost of two events firing, doubling CI load on every release.

Verification

Scenario	Expected	Result
`bun run lint` on the branch	clean	✅ biome check, 122 files, 0 fixes
`bun run typecheck` on the branch	clean	✅ `tsc --noEmit` exit 0
`bun test` on the branch	621 pass / 0 fail	✅ 621 pass, 1306 expect() calls
Trigger syntax (release: types: [published])	valid Forgejo schema	✅ matches the docs example
`ci.yaml` workflow_dispatch	unchanged	✅ still allows manual lint/typecheck/test/build/smoke

Out of scope

Retightening the Authorized Integration's event_name/ref claim rules — that's an admin-UI change, not a repo change. Once this lands and v0.5.2 has shipped green, the rules can be retightened in the Forgejo admin UI as a follow-up.
Post-mortem follow-ups #2 (clear-assets loud-fail), #3 (upload-assets retry), #4 (prepare-assets dist-clean), #7 (JWT pre-check) — deferred to v0.5.2 / v0.6.0.
The package-registry blast-radius concern raised by the looser event_name rule is unchanged by this PR; flagging it again here so a future maintainer retightening the rule knows what depends on it.

Risk carried

If the v0.5.1 post-mortem's "drafts didn't fire" claim is correct for this specific host build and the v16.0 docs are wrong, the next v0.5.2 draft will fail to trigger the workflow. Recovery is documented in AGENTS.md step 3 (delete release + tag, redo). Carrying this risk knowingly; the alternative (keeping workflow_dispatch as a permanent escape hatch) re-perpetuates the security-policy widening described above.

## Summary - `publish.yaml` triggers on `release: [published]` only; `workflow_dispatch` removed. - `derive-tag.sh` simplified: `FORGEJO_EVENT_RELEASE_TAG_NAME` is the only source of the tag. - `AGENTS.md` trigger note and procedure step 2 rewritten to match. ## Why - Symptom: the v0.5.1 release session shipped `release: published` + `workflow_dispatch` as the publish trigger. The dispatch arm was a workaround for a draft-first procedure that wasn't firing the workflow at the time, but on closer reading of the [Forgejo v16.0 actions docs](https://forge.sebatec.eu/forgejo/docs/user/actions/reference#onrelease), `release.published` *does* fire for draft releases on this host ("`published`: the release was created"). The dispatch arm is no longer needed and adds two failure modes: 1. With `ref`/`event_name` claim rules loosened in the Authorized Integration to let `workflow_dispatch` mint publishable JWTs, any future workflow added to this repo can mint a publishable token. Retightening requires admin-UI access, not a PR. 2. Dispatch against a SHA ref bypasses the tag ref the procedure is built around. - Root cause: the v0.5.1 post-mortem attributed "draft didn't fire" to a trigger mismatch; the actual behaviour on v16.0 is that drafts *do* fire `release.published`. The post-mortem narrative is wrong about Issue 1; the trigger fix landed in `f9bcfee` is the real change, and `workflow_dispatch` was scaffolding around the misdiagnosis. - Policy: the release is created up-front via plugin tools, which fires `release: published` against the tag ref. No fallback path is required; if a future draft doesn't fire, the recovery is the documented delete-and-redo flow. - Alternatives rejected: - `push: tags: ['v*']` instead — re-introduces the pre-`6d02892` coupling between `git push vX.Y.Z` and CI, and conflicts with the plugin-driven release flow in AGENTS.md. - `release: types: [created, published]` — keeps the manual-fallback ergonomic of dispatch but at the cost of two events firing, doubling CI load on every release. ## Verification | Scenario | Expected | Result | |---|---|---| | `bun run lint` on the branch | clean | ✅ biome check, 122 files, 0 fixes | | `bun run typecheck` on the branch | clean | ✅ `tsc --noEmit` exit 0 | | `bun test` on the branch | 621 pass / 0 fail | ✅ 621 pass, 1306 expect() calls | | Trigger syntax (release: types: [published]) | valid Forgejo schema | ✅ matches the docs example | | `ci.yaml` workflow_dispatch | unchanged | ✅ still allows manual lint/typecheck/test/build/smoke | ## Out of scope - Retightening the Authorized Integration's `event_name`/`ref` claim rules — that's an admin-UI change, not a repo change. Once this lands and v0.5.2 has shipped green, the rules can be retightened in the Forgejo admin UI as a follow-up. - Post-mortem follow-ups #2 (clear-assets loud-fail), #3 (upload-assets retry), #4 (prepare-assets dist-clean), #7 (JWT pre-check) — deferred to v0.5.2 / v0.6.0. - The package-registry blast-radius concern raised by the looser `event_name` rule is unchanged by this PR; flagging it again here so a future maintainer retightening the rule knows what depends on it. ## Risk carried If the v0.5.1 post-mortem's "drafts didn't fire" claim is correct for this specific host build and the v16.0 docs are wrong, the next v0.5.2 draft will fail to trigger the workflow. Recovery is documented in AGENTS.md step 3 (delete release + tag, redo). Carrying this risk knowingly; the alternative (keeping `workflow_dispatch` as a permanent escape hatch) re-perpetuates the security-policy widening described above.

ses added 1 commit

2026-09-04 22:27:45 +00:00

feat(workflows): drop workflow_dispatch from publish trigger

ci / test (pull_request) Successful in 1m14s

Details

publish / publish (release) Failing after 57s

Details

3f90124dbd

ses scheduled this pull request to auto merge when all checks succeed

2026-09-04 22:28:44 +00:00

ses merged commit 3f90124dbd into main

2026-09-04 22:29:01 +00:00