ci: never let the dependency-submission step withhold the GitHub assets

[bernardladenthin]

One line plus its rationale comment, closing a cross-repo parity gap — but the gap is not cosmetic, and it defeats a guarantee this pipeline was deliberately built to provide.

The guarantee

github-snapshot / github-release-signed run even when the Central publish fails:

if: ${{ !cancelled() && (needs.publish-snapshot.result == 'success' || needs.publish-snapshot.result == 'failure') && ... }}
# Also runs when publish-snapshot FAILED (not when skipped/cancelled): a Central
# publish-poll timeout reds that job after the artifacts were already uploaded —
# the GitHub pre-release assets must not be lost in that case.

Note the precise shape: it tolerates failure, not skipped.

The hole

The dependency-submission step sits in the report job unguarded, and report gates the entire chain:

report FAILS  (third-party informational action)
  └─> check-snapshot        SKIPPED   ← failed need; its if: is a plain event/ref
                                        condition, no always()/!cancelled() escape
       └─> publish-snapshot SKIPPED   ← if: check-snapshot.result == 'success'
            └─> github-snapshot       if: publish-snapshot ∈ {success, failure}
                                      'skipped' matches NEITHER → does not run

So the action having a bad day doesn't merely delay a Central publish — it silently loses the GitHub assets, which is exactly the outcome the if: above exists to prevent. The action submits the dependency graph to GitHub; it says nothing about whether the artifacts are correct, so it has no business gating anything.

Why it was missing here and not in srcmorph

srcmorph got this guard in passing, from ee2ae49 "ci: report unsigned assets without ever withholding them". That commit's actual feature was the unsigned-asset reporting, which was ported here — as 90dd21a, a single clean 68 insertions(+) change that reproduced the feature and did not touch the submission step. The drive-by line never travelled. So this is not a regression and not a design divergence; it is a port that copied the intent and missed an unrelated hardening bundled into the same upstream commit.

Scope — what deliberately stays bare

The convention being restored is narrow: informational third-party steps do not block. Within report, the submission action was the only step violating it —

step	before
actions/download-artifact	guarded
maven-dependency-submission-action	bare
Coveralls	guarded
Codecov	guarded

checkout and setup-java stay bare because they are infrastructure, not reports.

Verification

All four publish.yml files still parse; report still contains exactly one submission step; and the 5-line block (comment + uses: + flag) now hashes identically in all four repos — 5cbdaf64e4f4f303.

Companion PRs do the same in BitcoinAddressFinder and streambuffer.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH

---

Generated by Claude Code

[claude]

Review Summary

✅ Approved — This is a well-reasoned fix for a real pipeline guarantee.

What this fixes

The PR addresses a critical gap in the release pipeline's error handling:

• The guarantee: GitHub pre-release assets should land even when Central publish fails (gated by if: ... result == 'failure')
• The hole: The dependency-submission step was unguarded, causing report to fail and cascade to skip downstream jobs
• The result: If dependency-submission failed, github-snapshot would be skipped (not matching the 'success' or 'failure' conditions expected), silently losing GitHub assets

Quality observations

1. Correct implementation: The fix is minimal and follows established patterns in the same job (download-artifact, Coveralls, Codecov all have continue-on-error: true)

2. Well-documented: The added comment clearly explains why this flag is needed and the specific scenario it prevents — excellent for future maintainers

3. Upstream precedent: srcmorph already carries this guard, so this aligns with cross-repo conventions as documented in CLAUDE.md

4. No side effects: This change only affects error handling for an informational step; no business logic changes. Successful runs are unaffected.

5. Consistent scope: The fix narrows the guarantee correctly — informational third-party actions should not block the pipeline

Verification

✅ All informational steps in report now have continue-on-error: true
✅ The downstream github-snapshot and github-release-signed jobs still have their explicit failure-tolerant conditions
✅ File syntax is valid

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud