fix(workflows): restore derive-tag fallback, document v0.5.2 findings #36

Merged

ses merged 2 commits from feat/publish-trigger-fixes into main

2026-09-04 22:42:58 +00:00

ses commented

2026-09-04 22:41:30 +00:00

Owner

Summary

Two commits, two files. Restores the FORGEJO_REF_NAME fallback that PR #35 deleted, and documents two v0.5.2-empirical findings in AGENTS.md: drafts don't fire release: published on this host, and the runner does not populate FORGEJO_EVENT_RELEASE_TAG_NAME.

Why

Symptom: v0.5.2 release failed at publish:npm with ::error::Tag is not v-prefixed. The release page is currently live but empty (no assets, no npm package).
Root cause: PR #35 deleted the FORGEJO_REF_NAME fallback in scripts/publish/derive-tag.sh, relying on FORGEJO_EVENT_RELEASE_TAG_NAME always being set. Two checks confirm it isn't:
1. The Forgejo v16.0 docs (docs/user/actions/reference §env) enumerate every FORGEJO_* env var the runner guarantees. FORGEJO_EVENT_RELEASE_TAG_NAME is not in the list. Only generic variables (FORGEJO_REF, FORGEJO_REF_NAME, FORGEJO_SHA, ...) and FORGEJO_EVENT_PATH (JSON payload) are documented.
2. v0.5.1's pre-PR-#35 script worked because the fallback carried the tag from FORGEJO_REF=refs/tags/v0.5.1. v0.5.2's post-PR-#35 script failed because FORGEJO_EVENT_RELEASE_TAG_NAME was empty and no fallback existed.
Policy: keep the script robust to host-specific env var population. The fallback costs three lines and protects against this class of bug.
Alternative rejected: passing forgejo.event.release.tag_name via the workflow context and reading it from a different env var. More invasive (touches the workflow file), and the long-term fix should also include parsing FORGEJO_EVENT_PATH (the documented way to get release-specific data) — out of scope for this PR.
AGENTS.md fix: PR #35's claim that drafts fire release: published was based on the upstream v16.0 docs. On this host build (v16.0.3 + gitea-1.22.0) drafts do not fire. v0.5.2 confirmed empirically: the draft created at 22:33:54Z did not start publish.yaml; the same release recreated with draft: false fired it at 22:36:01Z. AGENTS.md is corrected.

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
`scripts/publish/derive-tag.sh` byte-equal to v0.5.1 form	yes	✅ 12 lines, identical to the pre-PR-#35 script
Live validation: redo v0.5.2 with the fix in place	workflow runs to terminal success, assets + npm package land on host	⏳ pending merge + v0.5.2 retry

Out of scope

Restoring package.json["version"] — AGENTS.md guardrail still says the published artifact's version comes from the tag, drift is expected.
Retightening the Authorized Integration's event_name/ref claim rules — admin-UI change, not a repo change. The loose rules were needed for the v0.5.1 dispatch path; now that workflow_dispatch is gone, retightening is a follow-up.
Parsing FORGEJO_EVENT_PATH JSON for release.tag_name — the proper long-term fix; defer to a separate PR.
Deleting the live-but-empty v0.5.2 release (id 559) — happens after this PR merges, before the v0.5.2 retry.

Follow-ups after merge

Delete release id 559 + tag v0.5.2 (per AGENTS.md step 3: delete the failed release and re-do from a fresh commit).
Re-create tag v0.5.2 at the merge commit (29ccdef).
create_release(v0.5.2, draft=false, body=<end-user note>) — the body's already drafted: "v0.5.2 ships no user-facing changes since v0.5.1. This release is tooling-only..."
watch_action_run to terminal status; report any failure per the report-only policy locked for v0.5.2.

## Summary Two commits, two files. Restores the `FORGEJO_REF_NAME` fallback that PR #35 deleted, and documents two v0.5.2-empirical findings in AGENTS.md: drafts don't fire `release: published` on this host, and the runner does not populate `FORGEJO_EVENT_RELEASE_TAG_NAME`. ## Why - **Symptom**: v0.5.2 release failed at `publish:npm` with `::error::Tag is not v-prefixed`. The release page is currently live but empty (no assets, no npm package). - **Root cause**: PR #35 deleted the `FORGEJO_REF_NAME` fallback in `scripts/publish/derive-tag.sh`, relying on `FORGEJO_EVENT_RELEASE_TAG_NAME` always being set. Two checks confirm it isn't: 1. The Forgejo v16.0 docs (`docs/user/actions/reference` §`env`) enumerate every `FORGEJO_*` env var the runner guarantees. `FORGEJO_EVENT_RELEASE_TAG_NAME` is **not in the list**. Only generic variables (`FORGEJO_REF`, `FORGEJO_REF_NAME`, `FORGEJO_SHA`, ...) and `FORGEJO_EVENT_PATH` (JSON payload) are documented. 2. v0.5.1's pre-PR-#35 script worked because the fallback carried the tag from `FORGEJO_REF=refs/tags/v0.5.1`. v0.5.2's post-PR-#35 script failed because `FORGEJO_EVENT_RELEASE_TAG_NAME` was empty and no fallback existed. - **Policy**: keep the script robust to host-specific env var population. The fallback costs three lines and protects against this class of bug. - **Alternative rejected**: passing `forgejo.event.release.tag_name` via the workflow context and reading it from a different env var. More invasive (touches the workflow file), and the long-term fix should also include parsing `FORGEJO_EVENT_PATH` (the documented way to get release-specific data) — out of scope for this PR. - **AGENTS.md fix**: PR #35's claim that drafts fire `release: published` was based on the upstream v16.0 docs. On this host build (v16.0.3 + gitea-1.22.0) drafts do not fire. v0.5.2 confirmed empirically: the draft created at 22:33:54Z did not start `publish.yaml`; the same release recreated with `draft: false` fired it at 22:36:01Z. AGENTS.md is corrected. ## 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 | | `scripts/publish/derive-tag.sh` byte-equal to v0.5.1 form | yes | ✅ 12 lines, identical to the pre-PR-#35 script | | Live validation: redo v0.5.2 with the fix in place | workflow runs to terminal success, assets + npm package land on host | ⏳ pending merge + v0.5.2 retry | ## Out of scope - Restoring `package.json["version"]` — AGENTS.md guardrail still says the published artifact's version comes from the tag, drift is expected. - Retightening the Authorized Integration's `event_name`/`ref` claim rules — admin-UI change, not a repo change. The loose rules were needed for the v0.5.1 dispatch path; now that `workflow_dispatch` is gone, retightening is a follow-up. - Parsing `FORGEJO_EVENT_PATH` JSON for `release.tag_name` — the proper long-term fix; defer to a separate PR. - Deleting the live-but-empty v0.5.2 release (id 559) — happens after this PR merges, before the v0.5.2 retry. ## Follow-ups after merge 1. Delete release id 559 + tag `v0.5.2` (per AGENTS.md step 3: delete the failed release and re-do from a fresh commit). 2. Re-create tag `v0.5.2` at the merge commit (`29ccdef`). 3. `create_release(v0.5.2, draft=false, body=<end-user note>)` — the body's already drafted: "v0.5.2 ships no user-facing changes since v0.5.1. This release is tooling-only..." 4. `watch_action_run` to terminal status; report any failure per the report-only policy locked for v0.5.2.

ses added 2 commits

2026-09-04 22:41:30 +00:00

fix(scripts): restore FORGEJO_REF_NAME fallback in derive-tag.sh d004f15f41

docs(agents): document v0.5.2 publish-workflow findings

ci / test (pull_request) Successful in 1m14s

Details

publish / publish (release) Failing after 1m4s

Details

29ccdef7b9

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

2026-09-04 22:42:03 +00:00

ses merged commit 29ccdef7b9 into main