fix(ci): allow for immutable GitHub releases

[wochinge]

Summary

• Move release artifact archive creation from a separate workflow step into release-it's after:bump hook
• Use release-it's github.assets to upload archives atomically with the GitHub release creation
• Remove the separate gh release upload --clobber step that allowed artifacts to be silently overwritten on re-runs
• Add release-artifacts/ to .gitignore

Context

Previously, the GitHub release was created by release-it and the artifact upload was a separate workflow step. This meant:

1. If the upload step failed, you'd have a release without artifacts and no clean retry path
2. The --clobber flag was needed as a workaround, but it also meant artifacts could be overwritten at any time

Now release-it handles both in a single atomic operation.

Test plan

• release-it --dry-run shows correct lifecycle ordering (bump → build → archive → release)
• Archive creation command produces all 6 package tarballs
• Run a pre-release (prepatch --preRelease=alpha) to verify end-to-end

🤖 Generated with Claude Code

Disclaimer: Experimental PR review

Greptile Summary

This PR consolidates GitHub release artifact creation and upload into release-it's after:bump hook and github.assets, replacing the former separate gh release upload --clobber step. The result is an atomic release where the GitHub release and its 6 tarballs are either created together or not at all, eliminating the previous race condition where a failed upload left a release without artifacts.

Confidence Score: 5/5

Safe to merge; the core atomic release logic is correct and the only finding is a stale comment in the rollback notification step.

All findings are P2. The implementation correctly moves archive creation into after:bump before the GitHub release is created, achieving the stated atomicity goal. The gitignore addition and config changes are clean. The single flagged issue (stale rollback message text) is a documentation-quality concern that doesn't affect runtime behavior.

.github/workflows/release.yml lines 498–509 — stale rollback guidance should be updated to reflect the new atomic flow.

Important Files Changed

Filename	Overview
.release-it.ci.json	Added archive creation in after:bump hook and github.assets glob; release-it now atomically creates the GitHub release with all 6 tarballs.
.github/workflows/release.yml	Workflow unchanged structurally; separate artifact upload step removed; rollback notification text is now stale after the atomic release change.
.gitignore	Added release-artifacts/ to prevent generated tarballs from being accidentally committed.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Workflow trigger] --> B[pnpm build + verify artifacts]
    B --> C[release-it: bump versions in package.json]
    C --> D["after:bump hook: pnpm build (versioned)"]
    D --> E["after:bump hook: tar all packages → release-artifacts/*.tar.gz"]
    E --> F[release-it: git commit + tag + push]
    F --> G["release-it: create GitHub release WITH assets (atomic)"]
    G --> H["after:release hook: pnpm -r publish to npm"]
    H --> I[Slack notification]

    G -- upload fails --> X[❌ Release creation fails — no orphaned release]
    D -- build fails --> Y[❌ Hook fails — no version bumped yet]

Loading

Comments Outside Diff (1)

1. .github/workflows/release.yml, line 498-509 (link)

   Stale rollback guidance

   With the new atomic approach, if steps.release succeeds, the GitHub release and its artifacts are already uploaded — there is nothing left to re-upload. Options 1 and 2 in this echo block no longer apply and could mislead an on-call engineer into performing unnecessary manual work. The only remaining failure scenario at this point is the Slack notification steps, which are non-critical.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: .github/workflows/release.yml
   Line: 498-509
   
   Comment:
   **Stale rollback guidance**
   
   With the new atomic approach, if `steps.release` succeeds, the GitHub release **and** its artifacts are already uploaded — there is nothing left to re-upload. Options 1 and 2 in this echo block no longer apply and could mislead an on-call engineer into performing unnecessary manual work. The only remaining failure scenario at this point is the Slack notification steps, which are non-critical.
   
   
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: .github/workflows/release.yml
Line: 498-509

Comment:
**Stale rollback guidance**

With the new atomic approach, if `steps.release` succeeds, the GitHub release **and** its artifacts are already uploaded — there is nothing left to re-upload. Options 1 and 2 in this echo block no longer apply and could mislead an on-call engineer into performing unnecessary manual work. The only remaining failure scenario at this point is the Slack notification steps, which are non-critical.

```suggestion
      - name: Rollback notification on partial failure
        if: failure() && steps.release.outcome == 'success'
        run: |
          echo "⚠️  CRITICAL: Release succeeded but a subsequent step failed"
          echo "Published version: v${STEPS_VERSION_OUTPUTS_VERSION}"
          echo ""
          echo "The GitHub release, artifacts, and npm packages were published successfully."
          echo "Only post-release steps (e.g. Slack notification) may have failed — check the workflow logs."
        env:
          STEPS_VERSION_OUTPUTS_VERSION: ${{ steps.version.outputs.version }}
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(ci): make GitHub release artifacts i..." | Re-trigger Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
langfuse-js	Ready	Preview	Apr 17, 2026 0:57am

[github-actions]

@claude review

[claude]

All three issues from my previous review have been addressed: set -e added for loop error propagation, the unintended v prefix removed from tarball filenames, and rollback guidance updated. LGTM.

Extended reasoning...

Overview

This PR moves GitHub release artifact creation and upload from separate workflow steps into release-it's after:bump hook and github.assets, making artifact upload atomic with the release creation. Three files are changed: .release-it.ci.json, .github/workflows/release.yml, and .gitignore.

Previous Review Feedback Addressed

My prior review flagged three issues, all of which the author resolved in commit 25420aa ('address review feedback for immutable releases'):

1. 🔴 Error handling: set -e; was added before the for loop, ensuring any failing tar invocation aborts the shell with a non-zero exit — release-it will then not create the GitHub release with incomplete artifacts.
2. 🟡 Filename v-prefix: The unintended v prefix in v${version}.tar.gz was removed, preserving the same naming convention as the old workflow.
3. 🟡 Stale rollback guidance: The rollback notification now accurately describes the atomic release model and removes the misleading 'Re-run' / 'Manually upload' options.

Security Risks

No security-sensitive code is touched. The PR does not affect authentication, permissions, or data handling. The release token (GH_ACCESS_TOKEN) usage is unchanged.

Level of Scrutiny

This is CI/release automation code. The changes are focused and the improvement (atomic release vs. two-step process) is clearly beneficial. The pattern of moving archive creation into release-it hooks is a well-understood approach.

Other Factors

No bugs were found by the automated bug hunting system in this pass. The bug hunting system's prior inline comments have all been addressed. The .gitignore addition is correct and unambiguous.