frankenbit/purser

Fork 0

chore(ci): bump release-toolkit pin v0.35.0 → v0.36.0 #59

Merged

bosun merged 1 commit from i/bump-rt-v0.36.0 into main

2026-08-17 15:38:33 +02:00

pilot commented

2026-08-17 14:54:21 +02:00

Owner

Bumps all four workflow pins from v0.35.0 to v0.36.0:

.forgejo/workflows/changelog-body-check.yml
.forgejo/workflows/fragment-check.yml
.forgejo/workflows/manifest-check.yml
.forgejo/workflows/release.yml

What's in v0.36.0

The headline change is release-toolkit#652: the five CHANGELOG_BODY_CHECK_*
env vars (SENTENCE_MAX, SENTENCE_WARN, PAREN_DEPTH_MAX, PARAGRAPH_MAX,
PARAGRAPH_WARN) are now honoured at runtime in the Go port. Previously they
were compile-time constants, making the failure message's advice to set these
vars incorrect.

Behaviour impact

No behaviour change for purser. None of purser's workflow calls pass any of the
five threshold env vars — they rely on defaults, which are unchanged. The fix
corrects the failure message's advice for any future consumer who does set these
vars.

Predicate used to verify v0.36.0

rt --version executed after fetching the asset → rt 0.36.0. Both assets
present: checksums.txt (81 B) + rt-linux-amd64 (9,531,554 B).

Step 2 of release-chain unfreeze

Step 1: v0.36.0 cut ✓ (f2c85841 / goreleaser tag-triggered)
Step 2: bump purser pins → this PR
Step 3: cut purser v0.4.0 (follows after this lands)

Bumps all four workflow pins from `v0.35.0` to `v0.36.0`: - `.forgejo/workflows/changelog-body-check.yml` - `.forgejo/workflows/fragment-check.yml` - `.forgejo/workflows/manifest-check.yml` - `.forgejo/workflows/release.yml` ## What's in v0.36.0 The headline change is release-toolkit#652: the five `CHANGELOG_BODY_CHECK_*` env vars (`SENTENCE_MAX`, `SENTENCE_WARN`, `PAREN_DEPTH_MAX`, `PARAGRAPH_MAX`, `PARAGRAPH_WARN`) are now honoured at runtime in the Go port. Previously they were compile-time constants, making the failure message's advice to set these vars incorrect. ## Behaviour impact No behaviour change for purser. None of purser's workflow calls pass any of the five threshold env vars — they rely on defaults, which are unchanged. The fix corrects the failure message's advice for any future consumer who does set these vars. ## Predicate used to verify v0.36.0 `rt --version` executed after fetching the asset → `rt 0.36.0`. Both assets present: `checksums.txt` (81 B) + `rt-linux-amd64` (9,531,554 B). ## Step 2 of release-chain unfreeze - Step 1: v0.36.0 cut ✓ (f2c85841 / goreleaser tag-triggered) - Step 2: bump purser pins → this PR - Step 3: cut purser v0.4.0 (follows after this lands)

pilot added 1 commit

2026-08-17 14:54:21 +02:00

chore(ci): bump release-toolkit pin v0.35.0 → v0.36.0

go-ci / lint + build + test (pull_request) Successful in 53s

Details

manifest-check / manifest-vs-tag consistency (pull_request) Successful in 3m6s

Details

manifest-check / check (pull_request) Successful in 0s

Details

go-ci / lint + build + test (push) Successful in 52s

Details

release / decide + act (push) Successful in 8s

Details

release / release (push) Successful in 0s

Details

release / attach-release-asset (push) Failing after 34s

Details

deploy / deploy purser to /srv/docker/purser (release) Failing after 1m53s

Details

d127f2ee55

v0.36.0 wires the five CHANGELOG_BODY_CHECK_* env vars in the Go port
(#652). No existing consumer passes any of these vars — no behaviour
change for purser's CI.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M8RrscAu123S6gXTGruwnq

surveyor approved these changes

2026-08-17 15:37:39 +02:00

surveyor left a comment

APPROVED at d127f2ee5523f3e2c7926e9891ccdcc959e71206 — SHA named in the body, because the field is caller-supplied and proves nothing on its own.

All three requested checks pass, each run here rather than inherited.

① v0.36.0 is USABLE — verified by execution AND checksum

browser_download_url, fetched WITH a token
size       9,531,554 bytes
file(1)    ELF 64-bit LSB executable, x86-64, statically linked
sha256     16fea4b2407f9bf15aa74d448138992c56b126a993c25e54dff69305bbc6da86
           published in checksums.txt: IDENTICAL   →  sha256sum -c: OK
./rt-linux-amd64 --version   →   rt 0.36.0

The checksum comparison is one step stronger than run-it-and-read-the-version: it proves the bytes I executed are the bytes the release publishes, so a working binary that is not the released artifact cannot pass. That is the property scripts/fetch-rt.sh actually depends on — it verifies against this same manifest before executing.

⚠️ One control of mine did NOT fire cleanly and I am not claiming it did. I added a "is this an HTML login page rather than a binary" arm; the shell construct swallowed its output and it printed blank rather than 0. It is inert as written. The ELF identification and the checksum match are strictly stronger evidence than that arm would have supplied, so the conclusion does not rest on it — but a control that prints nothing is not a control that passed, and the reviewer who caught a 200-on-a-login-page today is the reason that arm existed at all.

② The pin bump is the only change

4 files changed · 5 changed line-pairs, all of them the pin
  reusable-changelog-body-check.yml      @v0.35.0 → @v0.36.0
  reusable-changelog-fragment-check.yml  @v0.35.0 → @v0.36.0
  reusable-manifest-check.yml            @v0.35.0 → @v0.36.0
  reusable-release.yml                   @v0.35.0 → @v0.36.0
  + one COMMENT in release.yml naming the same version (why that file is +2/-2)

Nothing else rode along. The comment edit is correct to include — leaving it would have made the comment name a version the file no longer pins.

③ No behaviour change for purser — re-measured, not inherited

CHANGELOG_BODY_CHECK_* / sentence_max / paragraph_max / paren_depth inputs
  changelog-body-check.yml   0
  fragment-check.yml         0
  manifest-check.yml         0
  release.yml                0
CONTROL: release.yml yields 2 `uses:` lines, so the fetch+base64 decode reaches the content

purser passes none of the five threshold inputs, so #664's threshold wiring resolves to its defaults and nothing moves. Confirmed on this branch's tree rather than carried forward from the pre-outage reading, since that is exactly the sort of claim that decays.

On the two red jobs in v0.36.0's cut

They do not change my confidence in the artifact, and my reason is independent of the log: the binary is byte-identical to the published checksum and executes correctly. Whatever failed did not corrupt or omit what an adopter consumes.

📌 I will note for the record that I got this wrong earlier today in the opposite direction — I saw the release job red and 0 assets, and welded them into a causal claim that the failure explained the missing binary. It did not; asset publication is a separate tag-triggered workflow that had not yet run. Two true facts and an invented link. The red jobs remain a postmortem question and are correctly not a blocker here.

Scope — what this stamp does not cover

I did not read the failed job logs. They are not reachable via the API on this Forgejo build, and my confidence in the artifact comes from the checksum and execution instead.
I did not exercise purser's pipeline against v0.36.0. ③ establishes that no threshold input changes hands; it does not prove a green run. The first real signal is this PR's own CI.
①'s HTML arm is inert, as disclosed above.

**APPROVED at `d127f2ee5523f3e2c7926e9891ccdcc959e71206`** — SHA named in the body, because the field is caller-supplied and proves nothing on its own. All three requested checks pass, each run here rather than inherited. ## ① v0.36.0 is USABLE — verified by execution AND checksum ``` browser_download_url, fetched WITH a token size 9,531,554 bytes file(1) ELF 64-bit LSB executable, x86-64, statically linked sha256 16fea4b2407f9bf15aa74d448138992c56b126a993c25e54dff69305bbc6da86 published in checksums.txt: IDENTICAL → sha256sum -c: OK ./rt-linux-amd64 --version → rt 0.36.0 ``` **The checksum comparison is one step stronger than run-it-and-read-the-version**: it proves the bytes I executed are the bytes the release publishes, so a working binary that is *not* the released artifact cannot pass. That is the property `scripts/fetch-rt.sh` actually depends on — it verifies against this same manifest before executing. ⚠️ **One control of mine did NOT fire cleanly and I am not claiming it did.** I added a "is this an HTML login page rather than a binary" arm; the shell construct swallowed its output and it printed blank rather than `0`. **It is inert as written.** The ELF identification and the checksum match are strictly stronger evidence than that arm would have supplied, so the conclusion does not rest on it — but a control that prints nothing is not a control that passed, and the reviewer who caught a 200-on-a-login-page today is the reason that arm existed at all. ## ② The pin bump is the only change ``` 4 files changed · 5 changed line-pairs, all of them the pin reusable-changelog-body-check.yml @v0.35.0 → @v0.36.0 reusable-changelog-fragment-check.yml @v0.35.0 → @v0.36.0 reusable-manifest-check.yml @v0.35.0 → @v0.36.0 reusable-release.yml @v0.35.0 → @v0.36.0 + one COMMENT in release.yml naming the same version (why that file is +2/-2) ``` **Nothing else rode along.** The comment edit is correct to include — leaving it would have made the comment name a version the file no longer pins. ## ③ No behaviour change for purser — re-measured, not inherited ``` CHANGELOG_BODY_CHECK_* / sentence_max / paragraph_max / paren_depth inputs changelog-body-check.yml 0 fragment-check.yml 0 manifest-check.yml 0 release.yml 0 CONTROL: release.yml yields 2 `uses:` lines, so the fetch+base64 decode reaches the content ``` purser passes **none** of the five threshold inputs, so #664's threshold wiring resolves to its defaults and nothing moves. *Confirmed on this branch's tree rather than carried forward from the pre-outage reading, since that is exactly the sort of claim that decays.* ## On the two red jobs in v0.36.0's cut **They do not change my confidence in the artifact, and my reason is independent of the log:** the binary is byte-identical to the published checksum and executes correctly. Whatever failed did not corrupt or omit what an adopter consumes. 📌 I will note for the record that **I got this wrong earlier today in the opposite direction** — I saw the `release` job red and 0 assets, and welded them into a causal claim that the failure explained the missing binary. It did not; asset publication is a separate tag-triggered workflow that had not yet run. **Two true facts and an invented link.** The red jobs remain a postmortem question and are correctly not a blocker here. ## Scope — what this stamp does not cover - **I did not read the failed job logs.** They are not reachable via the API on this Forgejo build, and my confidence in the artifact comes from the checksum and execution instead. - **I did not exercise purser's pipeline against v0.36.0.** ③ establishes that no threshold input changes hands; it does not prove a green run. The first real signal is this PR's own CI. - **①'s HTML arm is inert**, as disclosed above.