ci(security): SHA-pin GitHub Actions in publish.yml (SEC-06)

[wisdommen]

SHA-pin GitHub Actions in publish.yml (SEC-06)

This PR applies a uses:-SHA-value-only pin to the three GitHub Actions in .github/workflows/publish.yml — pasting the canonical SHA values for the actions already referenced at @v4. No version bump (still # v4), no trigger / if: / with: / env: / needs: / step-order change. Part of GSD phase 28 (batch-3 cohort, plan 28-04).

Ref-as-written	Pinned SHA	Comment
actions/checkout@v4	34e114876b0b11c390a56381ad16ebd13914f8d5	# v4 (v4.3.1)
actions/setup-java@v4	c1e323688fd81a25caa38c78aa6df2d33d3e20d9	# v4 (v4.8.0)
actions/setup-node@v4	49933ea5288caeca8642d1e84afbd3f7d6820020	# v4 (v4.4.0)

Before → after pin lines

-      - uses: actions/checkout@v4
+      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5  # v4 (v4.3.1)
-        uses: actions/setup-java@v4
+        uses: actions/setup-java@c1e323688fd81a25caa38c78aa6df2d33d3e20d9  # v4 (v4.8.0)
-        uses: actions/setup-node@v4
+        uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020  # v4 (v4.4.0)

---

UltiTrade — C1–C6 no-release proof verdict (Archetype C, SEC-06)

Proof recorded in the 28-04 proof artifact (Task 1), re-verified against git diff origin/master in Task 3.

• C1 — Diff is SHA-value-only. The diff changes only the SHA token on the three mapped uses: lines confirmed @v4 on origin/master — L22 actions/checkout@v4, L27 actions/setup-java@v4, L94 actions/setup-node@v4 — plus a trailing # v4 (vX.Y.Z) comment, pasting the 26-02 §2c pin strings verbatim. No on:/trigger, no if:, no with:, no env:, no needs:, no step ordering or job-logic changes. git diff origin/master -- .github/workflows/publish.yml = exactly 3 changed lines. PASS
• C2 — Trigger model (leg a). on: push: branches: [master] (with paths-ignore) + workflow_dispatch. A SHA-pin commit on a feature branch targeting master via PR does not trigger the push: branches: [master] path until merge, and at merge the existing-version guard (C5) intercepts before any publish step. No pull_request trigger. PASS
• C3 — Guard (leg b). Single job release-and-publish (permissions: contents: write). Step check (Check if release exists) runs if gh release view "v${VERSION}" ... then EXISTS=true ... else EXISTS=false. Every subsequent publish step is gated if: steps.check.outputs.EXISTS == 'false'. PASS
• C4 — Diff-reachability = unreachable-to-publish (leg c). Because C1 holds, the trigger (C2) and the EXISTS guard (C3/C5) are byte-identical pre/post pin. The set of conditions under which any publish step runs is unchanged. The pin cannot alter pom.xml <version> nor the release state, so it cannot flip EXISTS. PASS
• C5 — Existing-version guard (Archetype C). Published release v1.0.0 exists on UltiKits/UltiTrade (tag v1.0.0 → d34c4028...), isDraft:false, isPrerelease:false. The EXISTS=true branch short-circuits every publish step unconditionally; a SHA-only pin on a feature branch cannot flip EXISTS. PASS
• C6 — Verdict. PASS — config-only pin, unreachable-to-publish.
  • master HEAD: 1a197b0 (origin/master)
  • publish.yml master sha256 36728f84... (pre == post; config-only)
  • publish.yml present on master (EXISTS=true)

---

EXISTS=true evidence

• Release v1.0.0 is published on UltiKits/UltiTrade (tag v1.0.0 → d34c4028..., isDraft:false, isPrerelease:false) — a published release, not a draft or prerelease.
• pom.xml project <version> resolves to 1.0.0, matching the published v1.0.0 tag, so the workflow's existing-version guard resolves EXISTS=true and short-circuits every publish step.
• master HEAD 1a197b0; publish.yml master sha256 36728f84....

Reference: GSD Phase 28 plan 28-04 proof artifact, maintainer token approve 28-04-cohort-batch-3.

---

Must NOT be merged until the maintainer's per-PR token with proof PASS + CI confirming no release/tag/publish fired.

[coderabbitai]

Warning

Review limit reached

@wisdommen, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes and 44 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more credits in the billing tab to continue.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 47d73aa7-642a-4f6b-9361-5d6b1666dcf2

📥 Commits

Reviewing files that changed from the base of the PR and between 1a197b0 and 5f8d0ca.

📒 Files selected for processing (1)

• .github/workflows/publish.yml

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/sha-pin-publish-yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}