feat: publish releases through stoke CLI #55

Merged
andres merged 4 commits from build/54-publish-release into main 2026-09-02 11:22:58 +00:00

Refs #54

Summary

  • vendor the ceremony 0.6.3 changelog-section extractor
  • publish release notes and assets through stoke's own CLI
  • replace the release workflow's hand-rolled token-bearing curl calls

Worklog

  • Claim #54 and record the implementation design
  • Establish the 133-test clean baseline
  • Implement and verify changelog section extraction
  • Implement and verify CLI-backed release publication
  • Update the release workflow and changelog fragment
  • Run the full acceptance and governance verification
  • Hand the complete head to the review engine

Acceptance criteria

  • No curl or Authorization token header remains in .forgejo/workflows/release.yml
  • npm test passes, including both new test files
  • scripts/changelog-section.sh extracts 1.4.0 and rejects missing 1.5.0
  • The release token reaches stoke only through --token-file, never argv
  • Existing releases upload while missing releases create, proven by stubbed tests
  • Post-merge verification remains with triage; this PR only references #54

Round log

Round at ee88d7d3

Round passed with no written reply.

Refs #54 ## Summary - vendor the ceremony 0.6.3 changelog-section extractor - publish release notes and assets through stoke's own CLI - replace the release workflow's hand-rolled token-bearing curl calls ## Worklog - [x] Claim #54 and record the implementation design - [x] Establish the 133-test clean baseline - [x] Implement and verify changelog section extraction - [x] Implement and verify CLI-backed release publication - [x] Update the release workflow and changelog fragment - [x] Run the full acceptance and governance verification - [x] Hand the complete head to the review engine ## Acceptance criteria - [x] No curl or Authorization token header remains in `.forgejo/workflows/release.yml` - [x] `npm test` passes, including both new test files - [x] `scripts/changelog-section.sh` extracts 1.4.0 and rejects missing 1.5.0 - [x] The release token reaches stoke only through `--token-file`, never argv - [x] Existing releases upload while missing releases create, proven by stubbed tests - [x] Post-merge verification remains with triage; this PR only references #54 ## Round log <!-- round:ee88d7d395b840d8ac9593f27d6656414fba79cb --> **Round at ee88d7d3** _Round passed with no written reply._
codex-bot-andresmgsl added 1 commit 2026-09-02 09:19:44 +00:00
test: specify changelog section extraction
Some checks failed
labels / labels (pull_request) Successful in 11s
ci / test (pull_request) Failing after 16s
1aa6dc26a1
forgejo-actions added the
blocker:ci-red
state:addressing
labels 2026-09-02 09:20:02 +00:00
codex-bot-andresmgsl changed title from feat: publish releases through stoke CLI to WIP: feat: publish releases through stoke CLI 2026-09-02 09:20:08 +00:00
codex-bot-andresmgsl added 1 commit 2026-09-02 09:21:18 +00:00
feat: extract publishable changelog sections
All checks were successful
labels / labels (pull_request) Successful in 13s
ci / test (pull_request) Successful in 17s
e3f4703e13
forgejo-actions added
scope:packaging
state:building
and removed
blocker:ci-red
state:addressing
labels 2026-09-02 09:21:37 +00:00
codex-bot-andresmgsl added 1 commit 2026-09-02 09:23:31 +00:00
feat: publish release assets through stoke
All checks were successful
labels / labels (pull_request) Successful in 12s
ci / test (pull_request) Successful in 17s
571e1b1f1f
codex-bot-andresmgsl added 1 commit 2026-09-02 09:24:27 +00:00
ci: delegate release publication to stoke
All checks were successful
labels / labels (pull_request) Successful in 12s
ci / test (pull_request) Successful in 17s
ee88d7d395
forgejo-actions added the
scope:ci
label 2026-09-02 09:24:35 +00:00
Author
Member

📣 round answered at head ee88d7d395

📣 round answered at head ee88d7d395b840d8ac9593f27d6656414fba79cb
codex-bot-andresmgsl changed title from WIP: feat: publish releases through stoke CLI to feat: publish releases through stoke CLI 2026-09-02 09:29:41 +00:00
codex-bot-andresmgsl requested review from glm-bot-andresmgsl 2026-09-02 09:30:54 +00:00
codex-bot-andresmgsl requested review from claude-bot-andresmgsl 2026-09-02 09:30:55 +00:00
codex-bot-andresmgsl requested review from kimi-bot-andresmgsl 2026-09-02 09:30:55 +00:00
codex-bot-andresmgsl added the
state:bots-reviewing
label 2026-09-02 09:30:56 +00:00
forgejo-actions removed the
state:building
label 2026-09-02 09:31:15 +00:00

🔎 reviewing head ee88d7d395

All six of #54's acceptance criteria settled at this head. Verdict: approve
(two non-blocking nits in the body).

🔎 reviewing head ee88d7d395b840d8ac9593f27d6656414fba79cb All six of #54's acceptance criteria settled at this head. Verdict: approve (two non-blocking nits in the body).

🔎 reviewing head ee88d7d395

  • verdict submitted and verified: APPROVE at head ee88d7d395 (2026-09-02T09:41:51Z); worktree removed
🔎 reviewing head ee88d7d395b840d8ac9593f27d6656414fba79cb - verdict submitted and verified: APPROVE at head ee88d7d395b8 (2026-09-02T09:41:51Z); worktree removed

🔎 reviewing head ee88d7d395

  • Verified: no curl / Authorization token in .forgejo/workflows/release.yml.
  • Verified: changelog-section.sh 1.4.0 extracts 21 lines; 1.5.0 exits 1 with reason.
  • Verified: publish-release.sh stubbed sequence is view→upload for existing release and view→create for missing release, token via --token-file mode 0600, never in argv.
  • Verified: shellcheck clean on both new scripts.
  • Could not run npm test or the node:test files: Node.js is not installed in this box. Relied on manual shell probes and reading the test files.
  • Ready to approve.
🔎 reviewing head ee88d7d395b840d8ac9593f27d6656414fba79cb - Verified: no curl / Authorization token in .forgejo/workflows/release.yml. - Verified: changelog-section.sh 1.4.0 extracts 21 lines; 1.5.0 exits 1 with reason. - Verified: publish-release.sh stubbed sequence is view→upload for existing release and view→create for missing release, token via --token-file mode 0600, never in argv. - Verified: shellcheck clean on both new scripts. - Could not run npm test or the node:test files: Node.js is not installed in this box. Relied on manual shell probes and reading the test files. - Ready to approve.
claude-bot-andresmgsl approved these changes 2026-09-02 09:41:42 +00:00
claude-bot-andresmgsl left a comment
Member

Approve at ee88d7d395b840d8ac9593f27d6656414fba79cb.

Reviewed in a detached worktree at the head with npm ci run first. Every one of #54's six acceptance criteria holds, the vendored extractor is byte-identical to its stated source, and both branches of the get-or-create path work against the real src/cli.js, not just the stub. Two non-blocking nits below.

Acceptance criteria

# criterion how I checked result
1 no curl, no Authorization: token in .forgejo/workflows/ git grep -n curl .forgejo/workflows/release.yml; git grep -rn "curl|Authorization" .forgejo/workflows/ all three exit 1 (no match)
2 npm test passes incl. both new files npm test 141 pass / 0 fail (133 baseline + 8 new)
3 1.4.0 → 21 lines exit 0; 1.5.0 → empty stdout, reason on stderr, exit 1 ran the script both ways 21 lines / 0 stderr bytes / exit 0; 0 stdout bytes / no section for '1.5.0' / exit 1
4 token only via --token-file, never argv test asserts it; I mutated --token-file "$TOKEN_FILE"--token "$RELEASE_TOKEN" test 7 fails on the mutation
5 get-or-create preserved, proven by stubbed test mutated the if to always-create tests 5 and 6 both fail
6 Refs #54, close stays with triage regex-scanned the whole PR body for close[sd]?/fix(e[sd])?/resolve[sd]? near any #N zero closing keywords; all three #54 occurrences are Refs #54, worklog prose, and "this PR only references #54"

What I ran beyond the criteria

The stubbed tests never exercise the real CLI, so I closed that gap: I stood up a localhost HTTP stub of the Forgejo release API and drove the real scripts/publish-release.sh → real node src/cli.js → stub, using the repo's real CHANGELOG.md.

  • Release absent (stub 404s on releases/tags/v1.4.0): GET /api/v1/userGET .../releases/tags/v1.4.0 (404) → POST .../releasesPOST .../releases/100/assets?name=stoke_1.4.0_all.deb. Exit 0. The create's body field carried the full 21-line 1.4.0 section — the empty-notes-pane defect #54 calls out is genuinely closed, not just plumbed.
  • Release present (seeded id 63): GET /user → two GET .../releases/tags/v1.4.0POST .../releases/63/assets. No POST /releases. Exit 0.
  • Config landed in /tmp/e2e/stoke-release.XXXXXX/config.json, never $HOME — §1.2 satisfied for real. Authorization: token … appeared only in the header, and the temp dir was gone afterwards.

The workflow run: line is executed by no CI job, so I ran it directly: parsed release.yml with a YAML loader, substituted ${{ github.ref_name }} / ${{ github.repository_owner }}, and executed it against a fake workspace. The nested "$(node -p "require('./package.json').version")" quoting resolves correctly — 5 args, [v1.4.0] [1.4.0] [dist/stoke_1.4.0_all.deb] [heavy-duty] [stoke]. With dist/ empty it fails loudly (${3:?usage…}, exit 1) rather than passing a shifted argument list.

Vendoring fidelity. Fetched lib/changelog.sh and bin/changelog-section at ceremony tag 0.6.3 and diffed: changelog_section and changelog_section_problem are byte-identical to upstream. The header comment records the tag and both source paths, as §2 requires. The one wrapper divergence — the diagnosis says "no publishable section" instead of upstream's message pointing at changelog-assemble — is right, since stoke has no assembler to point at.

Failure cases actually fail. Six mutations, five of which reddened the intended test (details in the nit below for the sixth):

mutation test that failed
--token-file--token "$RELEASE_TOKEN" authentication uses a 0600 token file…
always-create (drop the release view branch) existing release uploads… + missing release creates it…
awk drops if (found) exit extraction stops before the next version heading
changelog extraction moved after the release calls missing changelog section aborts before any release command
no-entries guard disabled heading without a list entry is rejected as empty

Conventions and gates. shellcheck clean on both new scripts (and on all of scripts/). npm run check:governance4 identities resolved; 5 scope rows valid. test/*.test.js is in the ruled residue allowlist at test/governance.test.js:218, so the two new test files don't trip #48's coverage gate. changelog.d/54.md matches the sibling fragments' shape and ends with the terminal (#54). citation. Both scripts follow publish-deb.sh's idiom — #!/usr/bin/env bash, set -euo pipefail, the ROOT= line, ${N:?usage…} positionals. Forge checks green at this head: ci / test and labels / labels.

Load-bearing constraints. No third-party action is added; the only uses: in the file is the pre-existing actions/checkout@v4, untouched by this diff. secrets.RELEASE_TOKEN is kept as the step's credential and ${{ github.token }} is not silently swapped in — §1.6's explicit non-goal, honoured. npm ci still precedes the release step at L28, so node src/cli.js can resolve commander.

One note on §1.5: the spec's literal STOKE="${STOKE:-node "$ROOT/src/cli.js"}" can't nest quotes that way; the run_stoke() function used instead is the correct expression of the same requirement, and the test substitutes the stub through it exactly as intended.

Nits — non-blocking, address at your discretion

  1. test/publish-release.test.js:105 is a vacuous assertion. assert.equal(fs.existsSync(auth.tokenFile), false, 'temporary credential file must be removed') can never fail: runScenario's finally block rmSyncs dir, and RUNNER_TEMP lives inside dir, so the token file is gone by the time the assertion runs regardless of what the script did. Confirmed by mutation — deleting trap 'rm -rf "$TMP"' EXIT from publish-release.sh still leaves 4/4 green. The cleanup genuinely works (my end-to-end run left no stoke-release.* under RUNNER_TEMP), so this is test strength, not a defect in the script. Moving the check inside runScenario, before the finally, would make it bite.

  2. README.md:1083-1085 is now stale. The scripts/ tree block still lists only build-deb.sh, publish-deb.sh, install-apt.sh; publish-release.sh and changelog-section.sh are missing. (The test/ block just above it was already stale before this PR — five files unlisted — so a one-line sweep of both would clear it. #54 doesn't ask for a README change, which is why this rides the approval.) A related touch: publish-release.sh's header is thinner than publish-deb.sh's and doesn't document the env vars it reads — RELEASE_TOKEN, FORGE_URL/GITHUB_SERVER_URL, RUNNER_TEMP, STOKE.

What I could not verify

  • AC6's post-merge half. I could not push a v* tag, and RELEASE_TOKEN is unset (escalated on #27), so the live "release exists, .deb attached, notes pane populated" check did not run. The issue assigns that to triage post-merge and does not gate the merge on it. I substituted the localhost end-to-end above, which exercises the same script and the same CLI code path against the same API shapes, but not the real forge.
  • Runner-side execution of release.yml. No Forgejo Actions runner is reachable from here, and ci / test does not execute the release workflow. I relied on a YAML parse plus direct execution of the substituted run: line, which covers the quoting and the argument vector but not ${{ }} expansion by the runner itself.
  • release view's 404 behaviour against the live forge. My stub returns 404 with a JSON body and the CLI exits non-zero as expected; I took the live-forge measurement (--tag v9.9.9HTTP status: 404, exit 1) from #54's table rather than re-running it.
**Approve** at `ee88d7d395b840d8ac9593f27d6656414fba79cb`. Reviewed in a detached worktree at the head with `npm ci` run first. Every one of #54's six acceptance criteria holds, the vendored extractor is byte-identical to its stated source, and both branches of the get-or-create path work against the *real* `src/cli.js`, not just the stub. Two non-blocking nits below. ## Acceptance criteria | # | criterion | how I checked | result | |---|---|---|---| | 1 | no `curl`, no `Authorization: token` in `.forgejo/workflows/` | `git grep -n curl .forgejo/workflows/release.yml`; `git grep -rn "curl\|Authorization" .forgejo/workflows/` | all three exit 1 (no match) ✅ | | 2 | `npm test` passes incl. both new files | `npm test` | 141 pass / 0 fail (133 baseline + 8 new) ✅ | | 3 | `1.4.0` → 21 lines exit 0; `1.5.0` → empty stdout, reason on stderr, exit 1 | ran the script both ways | 21 lines / 0 stderr bytes / exit 0; 0 stdout bytes / `no section for '1.5.0'` / exit 1 ✅ | | 4 | token only via `--token-file`, never argv | test asserts it; I mutated `--token-file "$TOKEN_FILE"` → `--token "$RELEASE_TOKEN"` | test 7 fails on the mutation ✅ | | 5 | get-or-create preserved, proven by stubbed test | mutated the `if` to always-create | tests 5 and 6 both fail ✅ | | 6 | `Refs #54`, close stays with triage | regex-scanned the whole PR body for `close[sd]?`/`fix(e[sd])?`/`resolve[sd]?` near any `#N` | zero closing keywords; all three `#54` occurrences are `Refs #54`, worklog prose, and "this PR only references #54" ✅ | ## What I ran beyond the criteria **The stubbed tests never exercise the real CLI**, so I closed that gap: I stood up a localhost HTTP stub of the Forgejo release API and drove the real `scripts/publish-release.sh` → real `node src/cli.js` → stub, using the repo's real `CHANGELOG.md`. - *Release absent* (stub 404s on `releases/tags/v1.4.0`): `GET /api/v1/user` → `GET .../releases/tags/v1.4.0` (404) → `POST .../releases` → `POST .../releases/100/assets?name=stoke_1.4.0_all.deb`. Exit 0. The create's `body` field carried the full 21-line `1.4.0` section — the empty-notes-pane defect #54 calls out is genuinely closed, not just plumbed. - *Release present* (seeded id 63): `GET /user` → two `GET .../releases/tags/v1.4.0` → `POST .../releases/63/assets`. **No `POST /releases`.** Exit 0. - Config landed in `/tmp/e2e/stoke-release.XXXXXX/config.json`, never `$HOME` — §1.2 satisfied for real. `Authorization: token …` appeared only in the header, and the temp dir was gone afterwards. **The workflow `run:` line is executed by no CI job**, so I ran it directly: parsed `release.yml` with a YAML loader, substituted `${{ github.ref_name }}` / `${{ github.repository_owner }}`, and executed it against a fake workspace. The nested `"$(node -p "require('./package.json').version")"` quoting resolves correctly — 5 args, `[v1.4.0] [1.4.0] [dist/stoke_1.4.0_all.deb] [heavy-duty] [stoke]`. With `dist/` empty it fails loudly (`${3:?usage…}`, exit 1) rather than passing a shifted argument list. **Vendoring fidelity.** Fetched `lib/changelog.sh` and `bin/changelog-section` at ceremony tag `0.6.3` and diffed: `changelog_section` and `changelog_section_problem` are **byte-identical** to upstream. The header comment records the tag and both source paths, as §2 requires. The one wrapper divergence — the diagnosis says "no publishable section" instead of upstream's message pointing at `changelog-assemble` — is right, since stoke has no assembler to point at. **Failure cases actually fail.** Six mutations, five of which reddened the intended test (details in the nit below for the sixth): | mutation | test that failed | |---|---| | `--token-file` → `--token "$RELEASE_TOKEN"` | `authentication uses a 0600 token file…` | | always-create (drop the `release view` branch) | `existing release uploads…` + `missing release creates it…` | | awk drops `if (found) exit` | `extraction stops before the next version heading` | | changelog extraction moved after the release calls | `missing changelog section aborts before any release command` | | no-entries guard disabled | `heading without a list entry is rejected as empty` | **Conventions and gates.** `shellcheck` clean on both new scripts (and on all of `scripts/`). `npm run check:governance` → `4 identities resolved; 5 scope rows valid`. `test/*.test.js` is in the ruled residue allowlist at `test/governance.test.js:218`, so the two new test files don't trip #48's coverage gate. `changelog.d/54.md` matches the sibling fragments' shape and ends with the terminal `(#54).` citation. Both scripts follow `publish-deb.sh`'s idiom — `#!/usr/bin/env bash`, `set -euo pipefail`, the `ROOT=` line, `${N:?usage…}` positionals. Forge checks green at this head: `ci / test` and `labels / labels`. **Load-bearing constraints.** No third-party action is added; the only `uses:` in the file is the pre-existing `actions/checkout@v4`, untouched by this diff. `secrets.RELEASE_TOKEN` is kept as the step's credential and `${{ github.token }}` is *not* silently swapped in — §1.6's explicit non-goal, honoured. `npm ci` still precedes the release step at L28, so `node src/cli.js` can resolve `commander`. One note on §1.5: the spec's literal `STOKE="${STOKE:-node "$ROOT/src/cli.js"}"` can't nest quotes that way; the `run_stoke()` function used instead is the correct expression of the same requirement, and the test substitutes the stub through it exactly as intended. ## Nits — non-blocking, address at your discretion 1. **`test/publish-release.test.js:105` is a vacuous assertion.** `assert.equal(fs.existsSync(auth.tokenFile), false, 'temporary credential file must be removed')` can never fail: `runScenario`'s `finally` block `rmSync`s `dir`, and `RUNNER_TEMP` lives inside `dir`, so the token file is gone by the time the assertion runs regardless of what the script did. Confirmed by mutation — deleting `trap 'rm -rf "$TMP"' EXIT` from `publish-release.sh` still leaves 4/4 green. The cleanup genuinely works (my end-to-end run left no `stoke-release.*` under `RUNNER_TEMP`), so this is test strength, not a defect in the script. Moving the check inside `runScenario`, before the `finally`, would make it bite. 2. **`README.md:1083-1085` is now stale.** The `scripts/` tree block still lists only `build-deb.sh`, `publish-deb.sh`, `install-apt.sh`; `publish-release.sh` and `changelog-section.sh` are missing. (The `test/` block just above it was already stale before this PR — five files unlisted — so a one-line sweep of both would clear it. #54 doesn't ask for a README change, which is why this rides the approval.) A related touch: `publish-release.sh`'s header is thinner than `publish-deb.sh`'s and doesn't document the env vars it reads — `RELEASE_TOKEN`, `FORGE_URL`/`GITHUB_SERVER_URL`, `RUNNER_TEMP`, `STOKE`. ## What I could not verify - **AC6's post-merge half.** I could not push a `v*` tag, and `RELEASE_TOKEN` is unset (escalated on #27), so the live "release exists, `.deb` attached, notes pane populated" check did not run. The issue assigns that to triage post-merge and does not gate the merge on it. I substituted the localhost end-to-end above, which exercises the same script and the same CLI code path against the same API shapes, but not the real forge. - **Runner-side execution of `release.yml`.** No Forgejo Actions runner is reachable from here, and `ci / test` does not execute the release workflow. I relied on a YAML parse plus direct execution of the substituted `run:` line, which covers the quoting and the argument vector but not `${{ }}` expansion by the runner itself. - **`release view`'s 404 behaviour against the live forge.** My stub returns 404 with a JSON body and the CLI exits non-zero as expected; I took the live-forge measurement (`--tag v9.9.9` → `HTTP status: 404`, exit 1) from #54's table rather than re-running it.
glm-bot-andresmgsl approved these changes 2026-09-02 09:41:56 +00:00
glm-bot-andresmgsl left a comment
Member

Verdict: approve — whole PR reviewed at head ee88d7d395 against issue #54, in a detached throwaway worktree.

Verified by running, not opining:

  • No curl remains in .forgejo/workflows/release.yml (git grep -n curl → empty) and no Authorization header is constructed anywhere under .forgejo/workflows/. All three curl calls and the RELEASE_ID plumbing are gone; the step is the single-line invocation from issue #54 §3, and steps 1–3 (checkout, npm ci && npm test, build-deb, publish-deb) are untouched — the npm-ci-before-release ordering the issue calls load-bearing is preserved.
  • npm ci && npm test: 141/141 pass (133 baseline + the 8 new tests across test/changelog-section.test.js and test/publish-release.test.js). CI on the head reports success.
  • scripts/changelog-section.sh 1.4.0 CHANGELOG.md → exactly the 21-line section, exit 0, empty stderr; 1.5.0 → 0 bytes on stdout, the reason on stderr, exit 1.
  • Failure paths probed live and they fail: missing RELEASE_TOKEN → exit 1; missing asset → exit 1; missing changelog section → aborts before any release subcommand fires (proven with STOKE=/bin/true: no release call happened).
  • Token discipline: the stubbed test asserts --token-file with mode 0600, the token value in no argv element, one shared --config under the temp dir, and the temp credential file gone after exit. publish-deb.sh, the tag convention, and the RELEASE_TOKEN secret question are untouched per the issue's non-goals; secrets.RELEASE_TOKEN stays this step's credential.
  • Vendoring fidelity: changelog_section and changelog_section_problem compared against heavy-duty/ceremony lib/changelog.sh + bin/changelog-section at tag 0.6.3 via the contents API — function bodies verbatim; the header comment records the source tag and paths.
  • Both new scripts are shellcheck-clean; npm run check:governance passes; changelog.d/54.md follows the existing fragment style.
  • Close discipline: the body says Refs #54 and no closing keyword precedes #54 anywhere in it — the post-merge close stays with triage as the issue directs.
  • Panel note: this repo's labels.conf panel= line includes me; this is a panel verdict, not advisory.

Could not verify, and what I relied on instead:

  • No live release publication was run (needs a real v* tag push and an operator-set RELEASE_TOKEN). Relied on: the issue's own measured CLI surfaces at the same base — src/cli.js is untouched by this PR, and I confirmed every flag the script uses (--config, auth login --url/--token-file, release view --tag --json, release upload --tag --asset, release create --title/--body-file/--asset) exists at the head — plus the stubbed two-branch tests and the live guard probes above.
  • A release view failure for non-404 reasons (network/auth) falls through to release create; this matches issue #54 §1.4 verbatim and the old workflow's behavior, so it is spec, not a defect.

Non-blocking nit (builder's discretion): the vendored wrapper's generic stderr line reads "has no publishable section for 'X'" where ceremony's bin/changelog-section says "has no section … the release PR assembles the section (changelog-assemble)"; the diagnosis line is verbatim, exit semantics identical, and stoke has no changelog-assemble to point at — fine as adapted.

Verdict: approve — whole PR reviewed at head ee88d7d395b840d8ac9593f27d6656414fba79cb against issue #54, in a detached throwaway worktree. Verified by running, not opining: - No curl remains in .forgejo/workflows/release.yml (`git grep -n curl` → empty) and no Authorization header is constructed anywhere under .forgejo/workflows/. All three curl calls and the RELEASE_ID plumbing are gone; the step is the single-line invocation from issue #54 §3, and steps 1–3 (checkout, npm ci && npm test, build-deb, publish-deb) are untouched — the npm-ci-before-release ordering the issue calls load-bearing is preserved. - `npm ci && npm test`: 141/141 pass (133 baseline + the 8 new tests across test/changelog-section.test.js and test/publish-release.test.js). CI on the head reports success. - `scripts/changelog-section.sh 1.4.0 CHANGELOG.md` → exactly the 21-line section, exit 0, empty stderr; `1.5.0` → 0 bytes on stdout, the reason on stderr, exit 1. - Failure paths probed live and they fail: missing RELEASE_TOKEN → exit 1; missing asset → exit 1; missing changelog section → aborts before any release subcommand fires (proven with STOKE=/bin/true: no release call happened). - Token discipline: the stubbed test asserts --token-file with mode 0600, the token value in no argv element, one shared --config under the temp dir, and the temp credential file gone after exit. publish-deb.sh, the tag convention, and the RELEASE_TOKEN secret question are untouched per the issue's non-goals; secrets.RELEASE_TOKEN stays this step's credential. - Vendoring fidelity: changelog_section and changelog_section_problem compared against heavy-duty/ceremony lib/changelog.sh + bin/changelog-section at tag 0.6.3 via the contents API — function bodies verbatim; the header comment records the source tag and paths. - Both new scripts are shellcheck-clean; `npm run check:governance` passes; changelog.d/54.md follows the existing fragment style. - Close discipline: the body says `Refs #54` and no closing keyword precedes #54 anywhere in it — the post-merge close stays with triage as the issue directs. - Panel note: this repo's labels.conf `panel=` line includes me; this is a panel verdict, not advisory. Could not verify, and what I relied on instead: - No live release publication was run (needs a real v* tag push and an operator-set RELEASE_TOKEN). Relied on: the issue's own measured CLI surfaces at the same base — src/cli.js is untouched by this PR, and I confirmed every flag the script uses (--config, auth login --url/--token-file, release view --tag --json, release upload --tag --asset, release create --title/--body-file/--asset) exists at the head — plus the stubbed two-branch tests and the live guard probes above. - A `release view` failure for non-404 reasons (network/auth) falls through to `release create`; this matches issue #54 §1.4 verbatim and the old workflow's behavior, so it is spec, not a defect. Non-blocking nit (builder's discretion): the vendored wrapper's generic stderr line reads "has no publishable section for 'X'" where ceremony's bin/changelog-section says "has no section … the release PR assembles the section (changelog-assemble)"; the diagnosis line is verbatim, exit semantics identical, and stoke has no changelog-assemble to point at — fine as adapted.
kimi-bot-andresmgsl approved these changes 2026-09-02 09:43:53 +00:00
kimi-bot-andresmgsl left a comment
Member

Approved at head ee88d7d395.

The PR meets the acceptance criteria from #54:

  • .forgejo/workflows/release.yml no longer contains curl or an Authorization: token header.
  • scripts/changelog-section.sh extracts the 21-line 1.4.0 section from CHANGELOG.md and exits 1 with a reason for the missing 1.5.0 section.
  • scripts/publish-release.sh passes the token only via --token-file (mode 0600) and never in argv; a stubbed run shows the get-or-create branches (release view exit 0 → release upload; exit 1 → release create --body-file --asset).
  • The PR uses Refs #54, leaving post-merge verification to triage, and adds changelog.d/54.md.

Verification gaps (named per reviewer doctrine): Node.js is not installed in this box, so I could not run npm test or the node:test files. I relied on manual shell probes of the two new scripts plus reading test/changelog-section.test.js and test/publish-release.test.js. shellcheck reports no issues on the new shell scripts.

Approved at head ee88d7d395b840d8ac9593f27d6656414fba79cb. The PR meets the acceptance criteria from #54: - `.forgejo/workflows/release.yml` no longer contains `curl` or an `Authorization: token` header. - `scripts/changelog-section.sh` extracts the 21-line `1.4.0` section from `CHANGELOG.md` and exits 1 with a reason for the missing `1.5.0` section. - `scripts/publish-release.sh` passes the token only via `--token-file` (mode `0600`) and never in `argv`; a stubbed run shows the get-or-create branches (`release view` exit 0 → `release upload`; exit 1 → `release create --body-file --asset`). - The PR uses `Refs #54`, leaving post-merge verification to triage, and adds `changelog.d/54.md`. Verification gaps (named per reviewer doctrine): Node.js is not installed in this box, so I could not run `npm test` or the `node:test` files. I relied on manual shell probes of the two new scripts plus reading `test/changelog-section.test.js` and `test/publish-release.test.js`. `shellcheck` reports no issues on the new shell scripts.
forgejo-actions added
state:needs-human
and removed
state:bots-reviewing
labels 2026-09-02 10:00:19 +00:00
codex-bot-andresmgsl requested review from andres 2026-09-02 10:06:01 +00:00
andres merged commit d6a21c9d9e into main 2026-09-02 11:22:58 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
4 participants
Notifications
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: heavy-duty/stoke#55
No description provided.