Skip to content

fix(release): count debug-symbols siblings separately in the SHA256SUMS guard - #6691

Merged
houko merged 2 commits into
mainfrom
fix/sha256sums-debug-symbols-count
Jul 31, 2026
Merged

houko merged 2 commits into
mainfrom
fix/sha256sums-debug-symbols-count

Conversation

@houko

@houko houko commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Sign Release Artifacts failed on v2026.7.31 with expected exactly 12 .sha256 siblings (one per matrix target across cli_* jobs), got 16 — after every artifact had already been built and published. It will fail the same way on every subsequent release until this lands.

Cause

#6677 ships debug symbols as their own release assets, adding four librefang-<target>-debug-symbols.tar.gz.sha256 files. The sibling-count guard in sign_release_artifacts assumes one .sha256 per platform target and is deliberately an equality — its comment says drift in either direction is a bug, and blocking releases is the intended loud failure. So the four new files read as four extra platforms.

v2026.7.31 is the first release cut since #6677 landed, so this is a first exposure rather than a regression. The guard behaved exactly as designed; the constant simply was not updated alongside the new assets, and the two kinds of sibling are not the same kind of thing.

Fix

Split the list before counting.

  • Platform binaries keep the strict = 12. A dropped or added matrix target still stops the release loudly, which is the whole point of the guard.
  • Debug symbols get 2..4, matching how they are actually produced: cli_mac fails outright when its .dSYM is missing (so both macOS targets are guaranteed), while the cross-compiled cli_linux targets only warn when the .dwp is absent — that asymmetry is deliberate per chore(release): ship debug symbols as a separate asset so crashes can be symbolized #6677, so a hard = 4 would take a release down over a diagnostic aid. Below 2 means the macOS hard-failure path did not hold, which is worth stopping for; 2 or 3 emits a warning.

The manifest itself is unchanged. The download loop and ls *.sha256 still read the full asset list, so every hash including the debug-symbols ones stays in SHA256SUMS and under the cosign signature — this touches only the count check.

Verification

The step was extracted from the workflow and run against the real v2026.7.31 asset list plus three boundary cases:

Scenario Assets Result
Real v2026.7.31 16 PASS (platform=12, symbols=4)
Linux symbols absent 14 PASS + warning (symbols=2)
All symbols absent 12 FAIL (macOS guarantee broken)
One platform target dropped 15 FAIL (platform=11)

YAML parses.

Note on scope

Found while verifying the v2026.7.31 release pipeline (#6688 / #6689 / #6690). Unrelated to those changes in cause, but it blocks every future release, so it is fixed here rather than deferred.

The other failing job on that release, Mobile / iOS (ipa), also failed on v2026.7.27 and is continue-on-error: true by design — left alone, as it needs Apple signing credentials rather than a code change.

…MS guard

#6677 added four `librefang-<target>-debug-symbols.tar.gz.sha256` assets but left the sibling-count guard at `EXPECTED_PLATFORMS=12`. The guard is deliberately an equality so matrix drift stops a release loudly, so the new assets read as four extra platforms: v2026.7.31 — the first release cut after #6677 landed — failed with `expected exactly 12 .sha256 siblings, got 16`, after every artifact had already been built and published.

Splits the list before counting. Platform binaries keep the strict `= 12`. Debug symbols get `2..4`, matching how they are produced: `cli_mac` fails when its .dSYM is missing so both macOS targets are guaranteed, while the cross-compiled `cli_linux` targets only warn when the .dwp is absent. Below 2 means the macOS hard-failure path did not hold and stops the release; 2 or 3 warns rather than failing over a diagnostic aid.

The manifest is unchanged — the download loop and `ls *.sha256` still read the full list, so every hash including debug-symbols stays in SHA256SUMS and under the cosign signature.

Verification: the guard was extracted from the workflow and run against the real v2026.7.31 asset list (16 → platform=12, symbols=4, PASS) plus three boundary cases: Linux symbols absent (14 → PASS with warning), all symbols absent (12 → FAIL), one platform target dropped (15 → FAIL). YAML parses.
@github-actions github-actions Bot added no-rust-required This task does not require Rust knowledge area/ci CI/CD and build tooling size/S 10-49 lines changed labels Jul 31, 2026

houko commented Jul 31, 2026

Copy link
Copy Markdown
Contributor Author

Daily automated review pass — CLAUDE.md compliance only.

Commit author identity: 0a2fbf7 ("style: rewrap new sha256sums-guard comments to one sentence per line") carries Claude <noreply@anthropic.com> as the git commit author, not just message text. CLAUDE.md's commit-msg hook exists specifically to catch this — it "rejects a commit whose author identity (git var GIT_AUTHOR_IDENT) resolves to Claude / Anthropic even when the message itself is clean." The message here is clean; the author identity is the problem. Before merge this either needs the commit's authorship corrected (amend/rebase), or a squash-merge (which discards per-commit authorship anyway) if that's an acceptable resolution.

Not fixing this myself: correcting it requires producing a replacement commit, and this session's own git identity is the identical Claude <noreply@anthropic.com> — I have no compliant identity to reattribute it to, so I'd just be trading one instance of the same violation for another.

Everything else checked out clean:

  • changelog.d/fixed/6691-sha256sums-debug-symbols-count.md is present, correctly sectioned, and ends (#6691) (@houko).
  • The new shell comments in release.yml follow the one-sentence-per-line prose rule (no CLAUDE.md hard-wrap violations).
  • The platform/debug-symbols split logic matches the PR description's stated verification table (12/4, 14/2+warn, 12/0→fail, 15/11→fail).

_Generated by Claude Code


Generated by Claude Code

@houko
houko merged commit 09ee79a into main Jul 31, 2026
32 checks passed
@houko
houko deleted the fix/sha256sums-debug-symbols-count branch July 31, 2026 12:23
@houko houko mentioned this pull request Aug 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/ci CI/CD and build tooling no-rust-required This task does not require Rust knowledge size/S 10-49 lines changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants