fix(ci): upload release assets to a draft before publishing#31
Conversation
The repo now has GitHub immutable releases enabled, which freeze a Release's assets the instant it is published. The single-shot softprops/action-gh-release step created the Release already-published and then uploaded the four artifacts, so the second-architecture zip failed with "Cannot upload asset ... to an immutable release" and left a published, zero-asset prerelease behind. Split the step in two, as softprops' own error hint recommends: create the Release as a draft (drafts stay mutable), upload every asset, then flip it to published with `gh release edit --draft=false`. The tag is created at publish time on the built commit, prerelease is preserved, and the downstream appcast/gh-pages/Homebrew steps run sequentially in the same job, so the draft-publishes-as-release.published quirk is moot.
Summary by CodeRabbit
WalkthroughThe GitHub Release publication step in the build-publish workflow is split into two phases. The existing combined step is replaced by a draft-creation step using 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches✨ Simplify code
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-publish.yml:
- Line 365: The softprops/action-gh-release action on line 365 is pinned to a
mutable version tag `@v3` instead of an immutable commit SHA, which violates the
workflow policy gate. Replace the version tag `@v3` with a full commit SHA (e.g.,
`@abc123def456`...) to ensure the action is pinned to a specific immutable commit.
You can find the appropriate commit SHA by checking the releases or commits of
the softprops/action-gh-release repository on GitHub.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 29757d28-dde2-4529-bc59-c052081524e8
📒 Files selected for processing (1)
.github/workflows/build-publish.yml
| # ... to an immutable release" partway through the upload — softprops' | ||
| # own hint is exactly this: "keep the release as a draft with | ||
| # draft: true, then publish it later from that draft." | ||
| uses: softprops/action-gh-release@v3 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify all workflow `uses:` references are pinned to full commit SHAs.
# Expected: third-party actions should use @<40-hex-sha>, not `@vN` tags.
rg -n '^\s*uses:\s*[^@]+@' .github/workflows \
| awk '
{
ref=$0
if (ref ~ /@[0-9a-fA-F]{40}\s*$/) status="PINNED"
else status="UNPINNED"
print status " :: " ref
}'Repository: oomol-lab/LockIME
Length of output: 530
🏁 Script executed:
sed -n '360,370p' .github/workflows/build-publish.yml | cat -nRepository: oomol-lab/LockIME
Length of output: 933
Pin the release action to an immutable commit SHA.
Line 365 uses softprops/action-gh-release@v3, which is mutable and currently violates your workflow policy gate (unpinned-uses). Please pin to a full commit SHA to harden the supply chain and keep CI policy-compliant.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 365-365: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[info] 365-365: action functionality is already included by the runner (superfluous-actions): use gh release in a script step
(superfluous-actions)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build-publish.yml at line 365, The
softprops/action-gh-release action on line 365 is pinned to a mutable version
tag `@v3` instead of an immutable commit SHA, which violates the workflow policy
gate. Replace the version tag `@v3` with a full commit SHA (e.g.,
`@abc123def456`...) to ensure the action is pinned to a specific immutable commit.
You can find the appropriate commit SHA by checking the releases or commits of
the softprops/action-gh-release repository on GitHub.
Source: Linters/SAST tools
Problem
The nightly Publish run #28069459209 failed at Tag & publish GitHub Release:
The repo now has GitHub immutable releases enabled: a Release's assets are frozen the moment it is published. The single-shot
softprops/action-gh-releasestep created the Release already published and then uploaded the four artifacts, so the upload failed partway through — leaving a published, zero-asset prereleasev1.4.1-beta.1(plus its tag) behind.Fix
Split the step in two, exactly as softprops' own error hint recommends:
draft: trueso the Release is created mutable; all four artifacts upload cleanly.gh release edit "$TAG" --draft=falseflips it to published. The tag is created at publish time on the built commit (github.sha),prereleaseis preserved (betas stay pre-releases / never "Latest"), and assets are already in place before immutability kicks in.The downstream steps (appcast → gh-pages, Homebrew dispatch) run sequentially in the same job and don't subscribe to
release.*events, so the draft-publishes-as-release.publisheddistinction doesn't affect them.Scope
build-publish.ymlis the only place that creates Releases;release.ymlandnightly.ymljust call it, so this one change covers both stable and beta channels.Follow-up (not in this PR)
The failed run left a broken, published, zero-asset prerelease
v1.4.1-beta.1+ tag. No Sparkle client references it (gh-pages was never updated), so it's harmless junk — but deleting the release and its tag lets the next nightly produce a cleanv1.4.1-beta.1and validate this fix end-to-end.