Skip to content

fix(ci): upload release assets to a draft before publishing#31

Merged
BlackHole1 merged 1 commit into
mainfrom
fix/immutable-release-draft-publish
Jun 24, 2026
Merged

fix(ci): upload release assets to a draft before publishing#31
BlackHole1 merged 1 commit into
mainfrom
fix/immutable-release-draft-publish

Conversation

@BlackHole1

Copy link
Copy Markdown
Member

Problem

The nightly Publish run #28069459209 failed at Tag & publish GitHub Release:

Cannot upload asset LockIME-1.4.1-beta.1-x86_64.zip to an immutable release. GitHub only allows asset uploads before a release is published…

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-release step created the Release already published and then uploaded the four artifacts, so the upload failed partway through — leaving a published, zero-asset prerelease v1.4.1-beta.1 (plus its tag) behind.

Fix

Split the step in two, exactly as softprops' own error hint recommends:

  1. Tag GitHub Release & upload assets (draft)draft: true so the Release is created mutable; all four artifacts upload cleanly.
  2. Publish GitHub Releasegh release edit "$TAG" --draft=false flips it to published. The tag is created at publish time on the built commit (github.sha), prerelease is 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.published distinction doesn't affect them.

Scope

build-publish.yml is the only place that creates Releases; release.yml and nightly.yml just 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 clean v1.4.1-beta.1 and validate this fix end-to-end.

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.
@coderabbitai

coderabbitai Bot commented Jun 24, 2026

Copy link
Copy Markdown

Review Change Stack

Summary by CodeRabbit

  • Chores
    • Optimized the continuous integration workflow for release publishing to ensure greater reliability in the asset upload process.

Walkthrough

The 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 softprops/action-gh-release@v3 with draft: true, which uploads all configured assets while the release remains unpublished. A new subsequent step then runs gh release edit "$TAG" --draft=false (authenticated via GH_TOKEN) to flip the release from draft to published, preserving the prerelease setting and keeping tag_name and target_commitish pinned to the built commit SHA.

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title follows the required format <type>(<scope>): <subject> with type='fix', scope='ci', and clearly describes the main change of uploading release assets to a draft before publishing.
Description check ✅ Passed The description is well-detailed and directly addresses the changeset, explaining the problem, the fix, and its scope in the context of the workflow modification.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
✨ Simplify code
  • Create PR with simplified code
  • Commit simplified code in branch fix/immutable-release-draft-publish

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between a24f146 and ce67883.

📒 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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 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 -n

Repository: 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

@BlackHole1 BlackHole1 merged commit 476a4d2 into main Jun 24, 2026
3 checks passed
@BlackHole1 BlackHole1 deleted the fix/immutable-release-draft-publish branch June 24, 2026 04:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant