Fix npm release recovery - #2830

Merged
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery
Aug 18, 2026
Merged

Fix npm release recovery#2830
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery

Conversation

@findolor

@findolorfindolor commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Motivation

The npm release workflow can leave Git and npm permanently out of sync. Run 31486644553 published raindex 0.0.1-alpha.244 and UI components 0.0.1-alpha.243, then failed to push its version commit because main advanced. Run 31487015421 consequently derived raindex 0.0.1-alpha.244 from the stale manifest and npm rejected the duplicate version.

This is not isolated to one run: #2815 previously had to synchronize package manifests after another partial two-package release.

Solution

  • Serialize npm release runs and skip a source commit once a newer main head supersedes it.
  • Reconcile each workspace independently against npm versions and exact tarball hashes before selecting a release version.
  • Preserve a Git-reserved version when npm is behind, adopt npm when the registry is ahead, and bump only when the selected published artifact differs.
  • Commit and push version reservations before changing npm, so a non-fast-forward failure cannot leave npm ahead of Git.
  • Allow the version-commit workflow run to recover automatically when neither, one, or both package publishes completed.
  • Publish only packages whose selected artifact is missing, while still rebuilding both release assets.
  • Create the tag only after required publishes succeed and recover a missing tag or GitHub release without republishing immutable versions.

Checks

  • nix run nixpkgs#actionlint -- .github/workflows/npm-package-release.yml
  • npx --no-install prettier --check .github/workflows/npm-package-release.yml
  • git diff --check
  • Simulated the live npm-ahead state: repository .243/.242, npm .244/.243; selected .245/.244.
  • Simulated a retry after committing .245/.244 with npm still behind; preserved both reserved versions without another bump.
  • Commit hooks passed, including no-consumer-prettier and yamlfmt.

Summary by CodeRabbit

  • Improvements
    • Release runs are now coordinated to prevent overlapping releases.
    • Release state is validated before publishing begins.
    • Package changes are detected more accurately before publishing.
    • Version updates are reserved before publication to reduce conflicting releases.
    • Release workflows can recover from partially completed runs.
    • Tags and release records are created only after successful package publication.
    • Unchanged packages can skip unnecessary versioning and publishing.

@coderabbitai

coderabbitaiBot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Important

Review skipped

No new commits to review since the last review.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0a99107c-a5fe-417f-9e2f-ee817011e8fd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ef8924e6-0084-406e-b5d5-5cd62b6b8a64

📥 Commits

Reviewing files that changed from the base of the PR and between df1fd1b and 4b9521e.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/npm-package-release.yml

📝 Walkthrough

Walkthrough

The npm release workflow now serializes runs, validates the current main head, reconciles package and registry state, commits required versions before publishing, and creates tags and GitHub releases after successful publication.

Changes

npm Release Workflow

Layer / File(s)Summary
Run serialization and head validation
.github/workflows/npm-package-release.yml
Concurrent release runs are serialized. The workflow identifies superseded commits and skips later release actions for them.
Package release-state reconciliation
.github/workflows/npm-package-release.yml
The workflow compares repository and npm package versions and tarball hashes. It handles first publishes, prerelease selection, dependency and lockfile updates, package-specific publish flags, and existing release state.
Version reservation and package publishing
.github/workflows/npm-package-release.yml
The workflow commits required package and lockfile version reservations before publishing. Tarball creation and publication use package-specific release flags.
Post-publish tag and GitHub release
.github/workflows/npm-package-release.yml
The workflow creates release tags after successful publication. It retains existing tags and creates GitHub releases only when required and absent.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
participant GitHubActions
participant MainBranch
participant NpmRegistry
participant GitHub
GitHubActions->>MainBranch: validate current main head
GitHubActions->>NpmRegistry: resolve package versions and tarball hashes
NpmRegistry-->>GitHubActions: return registry state
GitHubActions->>MainBranch: commit required version reservations
GitHubActions->>NpmRegistry: publish selected package tarballs
GitHubActions->>GitHub: create release tag after publishing
GitHubActions->>GitHub: create GitHub release when required
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check nameStatusExplanation
Docstring Coverage✅ PassedNo functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check✅ PassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes check✅ PassedCheck skipped because no linked issues were found for this pull request.
Description Check✅ PassedCheck skipped - CodeRabbit’s high-level summary is enabled.
Title check✅ PassedThe title clearly and concisely identifies the main change: improving npm release recovery.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch arda/fix-npm-release-recovery

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

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

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
.github/workflows/npm-package-release.yml (2)

352-357: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Create GitHub Release runs even when the release already exists.

The step condition uses only RELEASE_REQUIRED. GITHUB_RELEASE_EXISTS is computed at line 265 but never used in a step condition. softprops/action-gh-release@v2 updates an existing release by default, so this is not a failure, but it re-uploads the tarball assets on every recovery run. Gate the step on the existing-release state if you want the recovery path to be a no-op.

Note also that the tarball assets at lines 360-361 are only produced when RELEASE_REQUIRED is true, which matches this condition.

🤖 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/npm-package-release.yml around lines 352 - 357, Update the
Create GitHub Release step’s if condition to require both RELEASE_REQUIRED to be
true and GITHUB_RELEASE_EXISTS to indicate that no release already exists.
Preserve the existing tarball production condition and release configuration.

296-299: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value

Move ${{ ... }} expansions into env: blocks to satisfy zizmor.

zizmor flags template expansion inside run: bodies at lines 298, 306, 321, 331, 336, and 345-349. The values come from this workflow's own step, so the practical risk is low. The values still originate from repository files (package.json versions) and from npm pack output. Referencing them as shell variables removes the injection surface and clears the warnings.

♻️ Example for the tag step
 - name: Push release tag
if: ${{ env.RELEASE_REQUIRED == 'true' }}
+ env:+ RELEASE_TAG: ${{ env.RELEASE_TAG }}+ RELEASE_TAG_EXISTS: ${{ env.RELEASE_TAG_EXISTS }}
run: |
- if [ "${{ env.RELEASE_TAG_EXISTS }}" = false ]; then- git tag "${{ env.RELEASE_TAG }}"- git push origin "${{ env.RELEASE_TAG }}"+ if [ "$RELEASE_TAG_EXISTS" = false ]; then+ git tag "$RELEASE_TAG"+ git push origin "$RELEASE_TAG"
else
- echo "Tag ${{ env.RELEASE_TAG }} already exists"+ echo "Tag $RELEASE_TAG already exists"
fi

Also applies to: 304-306, 320-324, 329-331, 335-339, 344-350

🤖 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/npm-package-release.yml around lines 296 - 299, Move all
GitHub Actions expression expansions currently embedded in the run scripts
around the release commit, tag, publish, and packaging steps into step-level env
entries. Update the affected shell commands to reference those environment
variables instead, including values derived from RAINDEX_NEW_VERSION,
UC_NEW_VERSION, and npm pack output, while preserving the existing release
behavior.

Source: Linters/SAST tools

🤖 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/npm-package-release.yml:
- Around line 181-196: Update resolve_baseline_version to determine the highest
published semver rather than relying on npm view "$package_name@latest" version.
Compare the maximum registry version against repository_version and return the
higher baseline, preserving the repository fallback when no published versions
are available.
- Around line 198-224: Update the RAINDEX publish decision flow around
package_hash and the prerelease npm version step to verify each generated alpha
candidate with npm before publishing. After npm version prerelease selects a
candidate, query npm for that exact package version and continue incrementing
until the candidate is unused, while preserving the existing hash comparison and
publish behavior.
---
Nitpick comments:
In @.github/workflows/npm-package-release.yml:
- Around line 352-357: Update the Create GitHub Release step’s if condition to
require both RELEASE_REQUIRED to be true and GITHUB_RELEASE_EXISTS to indicate
that no release already exists. Preserve the existing tarball production
condition and release configuration.
- Around line 296-299: Move all GitHub Actions expression expansions currently
embedded in the run scripts around the release commit, tag, publish, and
packaging steps into step-level env entries. Update the affected shell commands
to reference those environment variables instead, including values derived from
RAINDEX_NEW_VERSION, UC_NEW_VERSION, and npm pack output, while preserving the
existing release behavior.
🪄 Autofix

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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fd2e4f2a-6844-4a5f-b4fe-ac246867df8b

📥 Commits

Reviewing files that changed from the base of the PR and between 16049a3 and df1fd1b.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml

Comment thread.github/workflows/npm-package-release.yml Outdated
Comment thread.github/workflows/npm-package-release.yml
@findolorfindolor self-assigned this Aug 12, 2026
@findolor
findolor requested a review from rouzweltAugust 13, 2026 11:26
@rouzwelt

Copy link
Copy Markdown
Contributor

@CodeRabbit review

@coderabbitai

coderabbitaiBot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor
⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@findolor
findolor merged commit 669d227 into mainAug 18, 2026
17 of 18 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bashset -euo pipefail
base="$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main)"printf'%s\n''--- base-to-HEAD diff stat ---'
git diff --stat "$base"...HEAD
printf'%s\n''--- changed files ---'
git diff --name-status "$base"...HEAD
printf'%s\n''--- workflow outline ---'
ast-grep outline .github/workflows/npm-package-release.yml --items all 2>/dev/null ||trueprintf'%s\n''--- workflow diff ---'
git diff --unified=20 "$base"...HEAD -- .github/workflows/npm-package-release.yml

Length of output: 22162


SIZE=L

You are interacting with an AI system.

Sign up for freeto 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.

2 participants

@findolor@rouzwelt
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Fix npm release recovery - #2830

Merged
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery
Aug 18, 2026
Merged

Fix npm release recovery#2830
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery

Conversation

@findolor

@findolorfindolor commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Motivation

The npm release workflow can leave Git and npm permanently out of sync. Run 31486644553 published raindex 0.0.1-alpha.244 and UI components 0.0.1-alpha.243, then failed to push its version commit because main advanced. Run 31487015421 consequently derived raindex 0.0.1-alpha.244 from the stale manifest and npm rejected the duplicate version.

This is not isolated to one run: #2815 previously had to synchronize package manifests after another partial two-package release.

Solution

  • Serialize npm release runs and skip a source commit once a newer main head supersedes it.
  • Reconcile each workspace independently against npm versions and exact tarball hashes before selecting a release version.
  • Preserve a Git-reserved version when npm is behind, adopt npm when the registry is ahead, and bump only when the selected published artifact differs.
  • Commit and push version reservations before changing npm, so a non-fast-forward failure cannot leave npm ahead of Git.
  • Allow the version-commit workflow run to recover automatically when neither, one, or both package publishes completed.
  • Publish only packages whose selected artifact is missing, while still rebuilding both release assets.
  • Create the tag only after required publishes succeed and recover a missing tag or GitHub release without republishing immutable versions.

Checks

  • nix run nixpkgs#actionlint -- .github/workflows/npm-package-release.yml
  • npx --no-install prettier --check .github/workflows/npm-package-release.yml
  • git diff --check
  • Simulated the live npm-ahead state: repository .243/.242, npm .244/.243; selected .245/.244.
  • Simulated a retry after committing .245/.244 with npm still behind; preserved both reserved versions without another bump.
  • Commit hooks passed, including no-consumer-prettier and yamlfmt.

Summary by CodeRabbit

  • Improvements
    • Release runs are now coordinated to prevent overlapping releases.
    • Release state is validated before publishing begins.
    • Package changes are detected more accurately before publishing.
    • Version updates are reserved before publication to reduce conflicting releases.
    • Release workflows can recover from partially completed runs.
    • Tags and release records are created only after successful package publication.
    • Unchanged packages can skip unnecessary versioning and publishing.

@coderabbitai

coderabbitaiBot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Important

Review skipped

No new commits to review since the last review.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0a99107c-a5fe-417f-9e2f-ee817011e8fd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ef8924e6-0084-406e-b5d5-5cd62b6b8a64

📥 Commits

Reviewing files that changed from the base of the PR and between df1fd1b and 4b9521e.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/npm-package-release.yml

📝 Walkthrough

Walkthrough

The npm release workflow now serializes runs, validates the current main head, reconciles package and registry state, commits required versions before publishing, and creates tags and GitHub releases after successful publication.

Changes

npm Release Workflow

Layer / File(s)Summary
Run serialization and head validation
.github/workflows/npm-package-release.yml
Concurrent release runs are serialized. The workflow identifies superseded commits and skips later release actions for them.
Package release-state reconciliation
.github/workflows/npm-package-release.yml
The workflow compares repository and npm package versions and tarball hashes. It handles first publishes, prerelease selection, dependency and lockfile updates, package-specific publish flags, and existing release state.
Version reservation and package publishing
.github/workflows/npm-package-release.yml
The workflow commits required package and lockfile version reservations before publishing. Tarball creation and publication use package-specific release flags.
Post-publish tag and GitHub release
.github/workflows/npm-package-release.yml
The workflow creates release tags after successful publication. It retains existing tags and creates GitHub releases only when required and absent.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
participant GitHubActions
participant MainBranch
participant NpmRegistry
participant GitHub
GitHubActions->>MainBranch: validate current main head
GitHubActions->>NpmRegistry: resolve package versions and tarball hashes
NpmRegistry-->>GitHubActions: return registry state
GitHubActions->>MainBranch: commit required version reservations
GitHubActions->>NpmRegistry: publish selected package tarballs
GitHubActions->>GitHub: create release tag after publishing
GitHubActions->>GitHub: create GitHub release when required
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check nameStatusExplanation
Docstring Coverage✅ PassedNo functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check✅ PassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes check✅ PassedCheck skipped because no linked issues were found for this pull request.
Description Check✅ PassedCheck skipped - CodeRabbit’s high-level summary is enabled.
Title check✅ PassedThe title clearly and concisely identifies the main change: improving npm release recovery.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch arda/fix-npm-release-recovery

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

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

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
.github/workflows/npm-package-release.yml (2)

352-357: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Create GitHub Release runs even when the release already exists.

The step condition uses only RELEASE_REQUIRED. GITHUB_RELEASE_EXISTS is computed at line 265 but never used in a step condition. softprops/action-gh-release@v2 updates an existing release by default, so this is not a failure, but it re-uploads the tarball assets on every recovery run. Gate the step on the existing-release state if you want the recovery path to be a no-op.

Note also that the tarball assets at lines 360-361 are only produced when RELEASE_REQUIRED is true, which matches this condition.

🤖 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/npm-package-release.yml around lines 352 - 357, Update the
Create GitHub Release step’s if condition to require both RELEASE_REQUIRED to be
true and GITHUB_RELEASE_EXISTS to indicate that no release already exists.
Preserve the existing tarball production condition and release configuration.

296-299: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value

Move ${{ ... }} expansions into env: blocks to satisfy zizmor.

zizmor flags template expansion inside run: bodies at lines 298, 306, 321, 331, 336, and 345-349. The values come from this workflow's own step, so the practical risk is low. The values still originate from repository files (package.json versions) and from npm pack output. Referencing them as shell variables removes the injection surface and clears the warnings.

♻️ Example for the tag step
 - name: Push release tag
if: ${{ env.RELEASE_REQUIRED == 'true' }}
+ env:+ RELEASE_TAG: ${{ env.RELEASE_TAG }}+ RELEASE_TAG_EXISTS: ${{ env.RELEASE_TAG_EXISTS }}
run: |
- if [ "${{ env.RELEASE_TAG_EXISTS }}" = false ]; then- git tag "${{ env.RELEASE_TAG }}"- git push origin "${{ env.RELEASE_TAG }}"+ if [ "$RELEASE_TAG_EXISTS" = false ]; then+ git tag "$RELEASE_TAG"+ git push origin "$RELEASE_TAG"
else
- echo "Tag ${{ env.RELEASE_TAG }} already exists"+ echo "Tag $RELEASE_TAG already exists"
fi

Also applies to: 304-306, 320-324, 329-331, 335-339, 344-350

🤖 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/npm-package-release.yml around lines 296 - 299, Move all
GitHub Actions expression expansions currently embedded in the run scripts
around the release commit, tag, publish, and packaging steps into step-level env
entries. Update the affected shell commands to reference those environment
variables instead, including values derived from RAINDEX_NEW_VERSION,
UC_NEW_VERSION, and npm pack output, while preserving the existing release
behavior.

Source: Linters/SAST tools

🤖 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/npm-package-release.yml:
- Around line 181-196: Update resolve_baseline_version to determine the highest
published semver rather than relying on npm view "$package_name@latest" version.
Compare the maximum registry version against repository_version and return the
higher baseline, preserving the repository fallback when no published versions
are available.
- Around line 198-224: Update the RAINDEX publish decision flow around
package_hash and the prerelease npm version step to verify each generated alpha
candidate with npm before publishing. After npm version prerelease selects a
candidate, query npm for that exact package version and continue incrementing
until the candidate is unused, while preserving the existing hash comparison and
publish behavior.
---
Nitpick comments:
In @.github/workflows/npm-package-release.yml:
- Around line 352-357: Update the Create GitHub Release step’s if condition to
require both RELEASE_REQUIRED to be true and GITHUB_RELEASE_EXISTS to indicate
that no release already exists. Preserve the existing tarball production
condition and release configuration.
- Around line 296-299: Move all GitHub Actions expression expansions currently
embedded in the run scripts around the release commit, tag, publish, and
packaging steps into step-level env entries. Update the affected shell commands
to reference those environment variables instead, including values derived from
RAINDEX_NEW_VERSION, UC_NEW_VERSION, and npm pack output, while preserving the
existing release behavior.
🪄 Autofix

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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fd2e4f2a-6844-4a5f-b4fe-ac246867df8b

📥 Commits

Reviewing files that changed from the base of the PR and between 16049a3 and df1fd1b.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml

Comment thread.github/workflows/npm-package-release.yml Outdated
Comment thread.github/workflows/npm-package-release.yml
@findolorfindolor self-assigned this Aug 12, 2026
@findolor
findolor requested a review from rouzweltAugust 13, 2026 11:26
@rouzwelt

Copy link
Copy Markdown
Contributor

@CodeRabbit review

@coderabbitai

coderabbitaiBot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor
⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@findolor
findolor merged commit 669d227 into mainAug 18, 2026
17 of 18 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bashset -euo pipefail
base="$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main)"printf'%s\n''--- base-to-HEAD diff stat ---'
git diff --stat "$base"...HEAD
printf'%s\n''--- changed files ---'
git diff --name-status "$base"...HEAD
printf'%s\n''--- workflow outline ---'
ast-grep outline .github/workflows/npm-package-release.yml --items all 2>/dev/null ||trueprintf'%s\n''--- workflow diff ---'
git diff --unified=20 "$base"...HEAD -- .github/workflows/npm-package-release.yml

Length of output: 22162


SIZE=L

You are interacting with an AI system.

Sign up for freeto 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.

2 participants

@findolor@rouzwelt
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Fix npm release recovery - #2830

Merged
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery
Aug 18, 2026
Merged

Fix npm release recovery#2830
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery

Conversation

@findolor

@findolorfindolor commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Motivation

The npm release workflow can leave Git and npm permanently out of sync. Run 31486644553 published raindex 0.0.1-alpha.244 and UI components 0.0.1-alpha.243, then failed to push its version commit because main advanced. Run 31487015421 consequently derived raindex 0.0.1-alpha.244 from the stale manifest and npm rejected the duplicate version.

This is not isolated to one run: #2815 previously had to synchronize package manifests after another partial two-package release.

Solution

  • Serialize npm release runs and skip a source commit once a newer main head supersedes it.
  • Reconcile each workspace independently against npm versions and exact tarball hashes before selecting a release version.
  • Preserve a Git-reserved version when npm is behind, adopt npm when the registry is ahead, and bump only when the selected published artifact differs.
  • Commit and push version reservations before changing npm, so a non-fast-forward failure cannot leave npm ahead of Git.
  • Allow the version-commit workflow run to recover automatically when neither, one, or both package publishes completed.
  • Publish only packages whose selected artifact is missing, while still rebuilding both release assets.
  • Create the tag only after required publishes succeed and recover a missing tag or GitHub release without republishing immutable versions.

Checks

  • nix run nixpkgs#actionlint -- .github/workflows/npm-package-release.yml
  • npx --no-install prettier --check .github/workflows/npm-package-release.yml
  • git diff --check
  • Simulated the live npm-ahead state: repository .243/.242, npm .244/.243; selected .245/.244.
  • Simulated a retry after committing .245/.244 with npm still behind; preserved both reserved versions without another bump.
  • Commit hooks passed, including no-consumer-prettier and yamlfmt.

Summary by CodeRabbit

  • Improvements
    • Release runs are now coordinated to prevent overlapping releases.
    • Release state is validated before publishing begins.
    • Package changes are detected more accurately before publishing.
    • Version updates are reserved before publication to reduce conflicting releases.
    • Release workflows can recover from partially completed runs.
    • Tags and release records are created only after successful package publication.
    • Unchanged packages can skip unnecessary versioning and publishing.

@coderabbitai

coderabbitaiBot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Important

Review skipped

No new commits to review since the last review.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0a99107c-a5fe-417f-9e2f-ee817011e8fd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ef8924e6-0084-406e-b5d5-5cd62b6b8a64

📥 Commits

Reviewing files that changed from the base of the PR and between df1fd1b and 4b9521e.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/npm-package-release.yml

📝 Walkthrough

Walkthrough

The npm release workflow now serializes runs, validates the current main head, reconciles package and registry state, commits required versions before publishing, and creates tags and GitHub releases after successful publication.

Changes

npm Release Workflow

Layer / File(s)Summary
Run serialization and head validation
.github/workflows/npm-package-release.yml
Concurrent release runs are serialized. The workflow identifies superseded commits and skips later release actions for them.
Package release-state reconciliation
.github/workflows/npm-package-release.yml
The workflow compares repository and npm package versions and tarball hashes. It handles first publishes, prerelease selection, dependency and lockfile updates, package-specific publish flags, and existing release state.
Version reservation and package publishing
.github/workflows/npm-package-release.yml
The workflow commits required package and lockfile version reservations before publishing. Tarball creation and publication use package-specific release flags.
Post-publish tag and GitHub release
.github/workflows/npm-package-release.yml
The workflow creates release tags after successful publication. It retains existing tags and creates GitHub releases only when required and absent.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
participant GitHubActions
participant MainBranch
participant NpmRegistry
participant GitHub
GitHubActions->>MainBranch: validate current main head
GitHubActions->>NpmRegistry: resolve package versions and tarball hashes
NpmRegistry-->>GitHubActions: return registry state
GitHubActions->>MainBranch: commit required version reservations
GitHubActions->>NpmRegistry: publish selected package tarballs
GitHubActions->>GitHub: create release tag after publishing
GitHubActions->>GitHub: create GitHub release when required
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check nameStatusExplanation
Docstring Coverage✅ PassedNo functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check✅ PassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes check✅ PassedCheck skipped because no linked issues were found for this pull request.
Description Check✅ PassedCheck skipped - CodeRabbit’s high-level summary is enabled.
Title check✅ PassedThe title clearly and concisely identifies the main change: improving npm release recovery.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch arda/fix-npm-release-recovery

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

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

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
.github/workflows/npm-package-release.yml (2)

352-357: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Create GitHub Release runs even when the release already exists.

The step condition uses only RELEASE_REQUIRED. GITHUB_RELEASE_EXISTS is computed at line 265 but never used in a step condition. softprops/action-gh-release@v2 updates an existing release by default, so this is not a failure, but it re-uploads the tarball assets on every recovery run. Gate the step on the existing-release state if you want the recovery path to be a no-op.

Note also that the tarball assets at lines 360-361 are only produced when RELEASE_REQUIRED is true, which matches this condition.

🤖 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/npm-package-release.yml around lines 352 - 357, Update the
Create GitHub Release step’s if condition to require both RELEASE_REQUIRED to be
true and GITHUB_RELEASE_EXISTS to indicate that no release already exists.
Preserve the existing tarball production condition and release configuration.

296-299: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value

Move ${{ ... }} expansions into env: blocks to satisfy zizmor.

zizmor flags template expansion inside run: bodies at lines 298, 306, 321, 331, 336, and 345-349. The values come from this workflow's own step, so the practical risk is low. The values still originate from repository files (package.json versions) and from npm pack output. Referencing them as shell variables removes the injection surface and clears the warnings.

♻️ Example for the tag step
 - name: Push release tag
if: ${{ env.RELEASE_REQUIRED == 'true' }}
+ env:+ RELEASE_TAG: ${{ env.RELEASE_TAG }}+ RELEASE_TAG_EXISTS: ${{ env.RELEASE_TAG_EXISTS }}
run: |
- if [ "${{ env.RELEASE_TAG_EXISTS }}" = false ]; then- git tag "${{ env.RELEASE_TAG }}"- git push origin "${{ env.RELEASE_TAG }}"+ if [ "$RELEASE_TAG_EXISTS" = false ]; then+ git tag "$RELEASE_TAG"+ git push origin "$RELEASE_TAG"
else
- echo "Tag ${{ env.RELEASE_TAG }} already exists"+ echo "Tag $RELEASE_TAG already exists"
fi

Also applies to: 304-306, 320-324, 329-331, 335-339, 344-350

🤖 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/npm-package-release.yml around lines 296 - 299, Move all
GitHub Actions expression expansions currently embedded in the run scripts
around the release commit, tag, publish, and packaging steps into step-level env
entries. Update the affected shell commands to reference those environment
variables instead, including values derived from RAINDEX_NEW_VERSION,
UC_NEW_VERSION, and npm pack output, while preserving the existing release
behavior.

Source: Linters/SAST tools

🤖 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/npm-package-release.yml:
- Around line 181-196: Update resolve_baseline_version to determine the highest
published semver rather than relying on npm view "$package_name@latest" version.
Compare the maximum registry version against repository_version and return the
higher baseline, preserving the repository fallback when no published versions
are available.
- Around line 198-224: Update the RAINDEX publish decision flow around
package_hash and the prerelease npm version step to verify each generated alpha
candidate with npm before publishing. After npm version prerelease selects a
candidate, query npm for that exact package version and continue incrementing
until the candidate is unused, while preserving the existing hash comparison and
publish behavior.
---
Nitpick comments:
In @.github/workflows/npm-package-release.yml:
- Around line 352-357: Update the Create GitHub Release step’s if condition to
require both RELEASE_REQUIRED to be true and GITHUB_RELEASE_EXISTS to indicate
that no release already exists. Preserve the existing tarball production
condition and release configuration.
- Around line 296-299: Move all GitHub Actions expression expansions currently
embedded in the run scripts around the release commit, tag, publish, and
packaging steps into step-level env entries. Update the affected shell commands
to reference those environment variables instead, including values derived from
RAINDEX_NEW_VERSION, UC_NEW_VERSION, and npm pack output, while preserving the
existing release behavior.
🪄 Autofix

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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fd2e4f2a-6844-4a5f-b4fe-ac246867df8b

📥 Commits

Reviewing files that changed from the base of the PR and between 16049a3 and df1fd1b.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml

Comment thread.github/workflows/npm-package-release.yml Outdated
Comment thread.github/workflows/npm-package-release.yml
@findolorfindolor self-assigned this Aug 12, 2026
@findolor
findolor requested a review from rouzweltAugust 13, 2026 11:26
@rouzwelt

Copy link
Copy Markdown
Contributor

@CodeRabbit review

@coderabbitai

coderabbitaiBot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor
⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@findolor
findolor merged commit 669d227 into mainAug 18, 2026
17 of 18 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bashset -euo pipefail
base="$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main)"printf'%s\n''--- base-to-HEAD diff stat ---'
git diff --stat "$base"...HEAD
printf'%s\n''--- changed files ---'
git diff --name-status "$base"...HEAD
printf'%s\n''--- workflow outline ---'
ast-grep outline .github/workflows/npm-package-release.yml --items all 2>/dev/null ||trueprintf'%s\n''--- workflow diff ---'
git diff --unified=20 "$base"...HEAD -- .github/workflows/npm-package-release.yml

Length of output: 22162


SIZE=L

You are interacting with an AI system.

Sign up for freeto 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.

2 participants

@findolor@rouzwelt
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Fix npm release recovery - #2830

Merged
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery
Aug 18, 2026
Merged

Fix npm release recovery#2830
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery

Conversation

@findolor

@findolorfindolor commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Motivation

The npm release workflow can leave Git and npm permanently out of sync. Run 31486644553 published raindex 0.0.1-alpha.244 and UI components 0.0.1-alpha.243, then failed to push its version commit because main advanced. Run 31487015421 consequently derived raindex 0.0.1-alpha.244 from the stale manifest and npm rejected the duplicate version.

This is not isolated to one run: #2815 previously had to synchronize package manifests after another partial two-package release.

Solution

  • Serialize npm release runs and skip a source commit once a newer main head supersedes it.
  • Reconcile each workspace independently against npm versions and exact tarball hashes before selecting a release version.
  • Preserve a Git-reserved version when npm is behind, adopt npm when the registry is ahead, and bump only when the selected published artifact differs.
  • Commit and push version reservations before changing npm, so a non-fast-forward failure cannot leave npm ahead of Git.
  • Allow the version-commit workflow run to recover automatically when neither, one, or both package publishes completed.
  • Publish only packages whose selected artifact is missing, while still rebuilding both release assets.
  • Create the tag only after required publishes succeed and recover a missing tag or GitHub release without republishing immutable versions.

Checks

  • nix run nixpkgs#actionlint -- .github/workflows/npm-package-release.yml
  • npx --no-install prettier --check .github/workflows/npm-package-release.yml
  • git diff --check
  • Simulated the live npm-ahead state: repository .243/.242, npm .244/.243; selected .245/.244.
  • Simulated a retry after committing .245/.244 with npm still behind; preserved both reserved versions without another bump.
  • Commit hooks passed, including no-consumer-prettier and yamlfmt.

Summary by CodeRabbit

  • Improvements
    • Release runs are now coordinated to prevent overlapping releases.
    • Release state is validated before publishing begins.
    • Package changes are detected more accurately before publishing.
    • Version updates are reserved before publication to reduce conflicting releases.
    • Release workflows can recover from partially completed runs.
    • Tags and release records are created only after successful package publication.
    • Unchanged packages can skip unnecessary versioning and publishing.

@coderabbitai

coderabbitaiBot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Important

Review skipped

No new commits to review since the last review.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0a99107c-a5fe-417f-9e2f-ee817011e8fd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ef8924e6-0084-406e-b5d5-5cd62b6b8a64

📥 Commits

Reviewing files that changed from the base of the PR and between df1fd1b and 4b9521e.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/npm-package-release.yml

📝 Walkthrough

Walkthrough

The npm release workflow now serializes runs, validates the current main head, reconciles package and registry state, commits required versions before publishing, and creates tags and GitHub releases after successful publication.

Changes

npm Release Workflow

Layer / File(s)Summary
Run serialization and head validation
.github/workflows/npm-package-release.yml
Concurrent release runs are serialized. The workflow identifies superseded commits and skips later release actions for them.
Package release-state reconciliation
.github/workflows/npm-package-release.yml
The workflow compares repository and npm package versions and tarball hashes. It handles first publishes, prerelease selection, dependency and lockfile updates, package-specific publish flags, and existing release state.
Version reservation and package publishing
.github/workflows/npm-package-release.yml
The workflow commits required package and lockfile version reservations before publishing. Tarball creation and publication use package-specific release flags.
Post-publish tag and GitHub release
.github/workflows/npm-package-release.yml
The workflow creates release tags after successful publication. It retains existing tags and creates GitHub releases only when required and absent.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
participant GitHubActions
participant MainBranch
participant NpmRegistry
participant GitHub
GitHubActions->>MainBranch: validate current main head
GitHubActions->>NpmRegistry: resolve package versions and tarball hashes
NpmRegistry-->>GitHubActions: return registry state
GitHubActions->>MainBranch: commit required version reservations
GitHubActions->>NpmRegistry: publish selected package tarballs
GitHubActions->>GitHub: create release tag after publishing
GitHubActions->>GitHub: create GitHub release when required
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check nameStatusExplanation
Docstring Coverage✅ PassedNo functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check✅ PassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes check✅ PassedCheck skipped because no linked issues were found for this pull request.
Description Check✅ PassedCheck skipped - CodeRabbit’s high-level summary is enabled.
Title check✅ PassedThe title clearly and concisely identifies the main change: improving npm release recovery.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch arda/fix-npm-release-recovery

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

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

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
.github/workflows/npm-package-release.yml (2)

352-357: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Create GitHub Release runs even when the release already exists.

The step condition uses only RELEASE_REQUIRED. GITHUB_RELEASE_EXISTS is computed at line 265 but never used in a step condition. softprops/action-gh-release@v2 updates an existing release by default, so this is not a failure, but it re-uploads the tarball assets on every recovery run. Gate the step on the existing-release state if you want the recovery path to be a no-op.

Note also that the tarball assets at lines 360-361 are only produced when RELEASE_REQUIRED is true, which matches this condition.

🤖 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/npm-package-release.yml around lines 352 - 357, Update the
Create GitHub Release step’s if condition to require both RELEASE_REQUIRED to be
true and GITHUB_RELEASE_EXISTS to indicate that no release already exists.
Preserve the existing tarball production condition and release configuration.

296-299: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value

Move ${{ ... }} expansions into env: blocks to satisfy zizmor.

zizmor flags template expansion inside run: bodies at lines 298, 306, 321, 331, 336, and 345-349. The values come from this workflow's own step, so the practical risk is low. The values still originate from repository files (package.json versions) and from npm pack output. Referencing them as shell variables removes the injection surface and clears the warnings.

♻️ Example for the tag step
 - name: Push release tag
if: ${{ env.RELEASE_REQUIRED == 'true' }}
+ env:+ RELEASE_TAG: ${{ env.RELEASE_TAG }}+ RELEASE_TAG_EXISTS: ${{ env.RELEASE_TAG_EXISTS }}
run: |
- if [ "${{ env.RELEASE_TAG_EXISTS }}" = false ]; then- git tag "${{ env.RELEASE_TAG }}"- git push origin "${{ env.RELEASE_TAG }}"+ if [ "$RELEASE_TAG_EXISTS" = false ]; then+ git tag "$RELEASE_TAG"+ git push origin "$RELEASE_TAG"
else
- echo "Tag ${{ env.RELEASE_TAG }} already exists"+ echo "Tag $RELEASE_TAG already exists"
fi

Also applies to: 304-306, 320-324, 329-331, 335-339, 344-350

🤖 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/npm-package-release.yml around lines 296 - 299, Move all
GitHub Actions expression expansions currently embedded in the run scripts
around the release commit, tag, publish, and packaging steps into step-level env
entries. Update the affected shell commands to reference those environment
variables instead, including values derived from RAINDEX_NEW_VERSION,
UC_NEW_VERSION, and npm pack output, while preserving the existing release
behavior.

Source: Linters/SAST tools

🤖 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/npm-package-release.yml:
- Around line 181-196: Update resolve_baseline_version to determine the highest
published semver rather than relying on npm view "$package_name@latest" version.
Compare the maximum registry version against repository_version and return the
higher baseline, preserving the repository fallback when no published versions
are available.
- Around line 198-224: Update the RAINDEX publish decision flow around
package_hash and the prerelease npm version step to verify each generated alpha
candidate with npm before publishing. After npm version prerelease selects a
candidate, query npm for that exact package version and continue incrementing
until the candidate is unused, while preserving the existing hash comparison and
publish behavior.
---
Nitpick comments:
In @.github/workflows/npm-package-release.yml:
- Around line 352-357: Update the Create GitHub Release step’s if condition to
require both RELEASE_REQUIRED to be true and GITHUB_RELEASE_EXISTS to indicate
that no release already exists. Preserve the existing tarball production
condition and release configuration.
- Around line 296-299: Move all GitHub Actions expression expansions currently
embedded in the run scripts around the release commit, tag, publish, and
packaging steps into step-level env entries. Update the affected shell commands
to reference those environment variables instead, including values derived from
RAINDEX_NEW_VERSION, UC_NEW_VERSION, and npm pack output, while preserving the
existing release behavior.
🪄 Autofix

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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fd2e4f2a-6844-4a5f-b4fe-ac246867df8b

📥 Commits

Reviewing files that changed from the base of the PR and between 16049a3 and df1fd1b.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml

Comment thread.github/workflows/npm-package-release.yml Outdated
Comment thread.github/workflows/npm-package-release.yml
@findolorfindolor self-assigned this Aug 12, 2026
@findolor
findolor requested a review from rouzweltAugust 13, 2026 11:26
@rouzwelt

Copy link
Copy Markdown
Contributor

@CodeRabbit review

@coderabbitai

coderabbitaiBot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor
⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@findolor
findolor merged commit 669d227 into mainAug 18, 2026
17 of 18 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bashset -euo pipefail
base="$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main)"printf'%s\n''--- base-to-HEAD diff stat ---'
git diff --stat "$base"...HEAD
printf'%s\n''--- changed files ---'
git diff --name-status "$base"...HEAD
printf'%s\n''--- workflow outline ---'
ast-grep outline .github/workflows/npm-package-release.yml --items all 2>/dev/null ||trueprintf'%s\n''--- workflow diff ---'
git diff --unified=20 "$base"...HEAD -- .github/workflows/npm-package-release.yml

Length of output: 22162


SIZE=L

You are interacting with an AI system.

Sign up for freeto 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.

2 participants

@findolor@rouzwelt
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Fix npm release recovery - #2830

Merged
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery
Aug 18, 2026
Merged

Fix npm release recovery#2830
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery

Conversation

@findolor

@findolorfindolor commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Motivation

The npm release workflow can leave Git and npm permanently out of sync. Run 31486644553 published raindex 0.0.1-alpha.244 and UI components 0.0.1-alpha.243, then failed to push its version commit because main advanced. Run 31487015421 consequently derived raindex 0.0.1-alpha.244 from the stale manifest and npm rejected the duplicate version.

This is not isolated to one run: #2815 previously had to synchronize package manifests after another partial two-package release.

Solution

  • Serialize npm release runs and skip a source commit once a newer main head supersedes it.
  • Reconcile each workspace independently against npm versions and exact tarball hashes before selecting a release version.
  • Preserve a Git-reserved version when npm is behind, adopt npm when the registry is ahead, and bump only when the selected published artifact differs.
  • Commit and push version reservations before changing npm, so a non-fast-forward failure cannot leave npm ahead of Git.
  • Allow the version-commit workflow run to recover automatically when neither, one, or both package publishes completed.
  • Publish only packages whose selected artifact is missing, while still rebuilding both release assets.
  • Create the tag only after required publishes succeed and recover a missing tag or GitHub release without republishing immutable versions.

Checks

  • nix run nixpkgs#actionlint -- .github/workflows/npm-package-release.yml
  • npx --no-install prettier --check .github/workflows/npm-package-release.yml
  • git diff --check
  • Simulated the live npm-ahead state: repository .243/.242, npm .244/.243; selected .245/.244.
  • Simulated a retry after committing .245/.244 with npm still behind; preserved both reserved versions without another bump.
  • Commit hooks passed, including no-consumer-prettier and yamlfmt.

Summary by CodeRabbit

  • Improvements
    • Release runs are now coordinated to prevent overlapping releases.
    • Release state is validated before publishing begins.
    • Package changes are detected more accurately before publishing.
    • Version updates are reserved before publication to reduce conflicting releases.
    • Release workflows can recover from partially completed runs.
    • Tags and release records are created only after successful package publication.
    • Unchanged packages can skip unnecessary versioning and publishing.

@coderabbitai

coderabbitaiBot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Important

Review skipped

No new commits to review since the last review.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0a99107c-a5fe-417f-9e2f-ee817011e8fd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ef8924e6-0084-406e-b5d5-5cd62b6b8a64

📥 Commits

Reviewing files that changed from the base of the PR and between df1fd1b and 4b9521e.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/npm-package-release.yml

📝 Walkthrough

Walkthrough

The npm release workflow now serializes runs, validates the current main head, reconciles package and registry state, commits required versions before publishing, and creates tags and GitHub releases after successful publication.

Changes

npm Release Workflow

Layer / File(s)Summary
Run serialization and head validation
.github/workflows/npm-package-release.yml
Concurrent release runs are serialized. The workflow identifies superseded commits and skips later release actions for them.
Package release-state reconciliation
.github/workflows/npm-package-release.yml
The workflow compares repository and npm package versions and tarball hashes. It handles first publishes, prerelease selection, dependency and lockfile updates, package-specific publish flags, and existing release state.
Version reservation and package publishing
.github/workflows/npm-package-release.yml
The workflow commits required package and lockfile version reservations before publishing. Tarball creation and publication use package-specific release flags.
Post-publish tag and GitHub release
.github/workflows/npm-package-release.yml
The workflow creates release tags after successful publication. It retains existing tags and creates GitHub releases only when required and absent.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
participant GitHubActions
participant MainBranch
participant NpmRegistry
participant GitHub
GitHubActions->>MainBranch: validate current main head
GitHubActions->>NpmRegistry: resolve package versions and tarball hashes
NpmRegistry-->>GitHubActions: return registry state
GitHubActions->>MainBranch: commit required version reservations
GitHubActions->>NpmRegistry: publish selected package tarballs
GitHubActions->>GitHub: create release tag after publishing
GitHubActions->>GitHub: create GitHub release when required
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check nameStatusExplanation
Docstring Coverage✅ PassedNo functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check✅ PassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes check✅ PassedCheck skipped because no linked issues were found for this pull request.
Description Check✅ PassedCheck skipped - CodeRabbit’s high-level summary is enabled.
Title check✅ PassedThe title clearly and concisely identifies the main change: improving npm release recovery.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch arda/fix-npm-release-recovery

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

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

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
.github/workflows/npm-package-release.yml (2)

352-357: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Create GitHub Release runs even when the release already exists.

The step condition uses only RELEASE_REQUIRED. GITHUB_RELEASE_EXISTS is computed at line 265 but never used in a step condition. softprops/action-gh-release@v2 updates an existing release by default, so this is not a failure, but it re-uploads the tarball assets on every recovery run. Gate the step on the existing-release state if you want the recovery path to be a no-op.

Note also that the tarball assets at lines 360-361 are only produced when RELEASE_REQUIRED is true, which matches this condition.

🤖 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/npm-package-release.yml around lines 352 - 357, Update the
Create GitHub Release step’s if condition to require both RELEASE_REQUIRED to be
true and GITHUB_RELEASE_EXISTS to indicate that no release already exists.
Preserve the existing tarball production condition and release configuration.

296-299: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value

Move ${{ ... }} expansions into env: blocks to satisfy zizmor.

zizmor flags template expansion inside run: bodies at lines 298, 306, 321, 331, 336, and 345-349. The values come from this workflow's own step, so the practical risk is low. The values still originate from repository files (package.json versions) and from npm pack output. Referencing them as shell variables removes the injection surface and clears the warnings.

♻️ Example for the tag step
 - name: Push release tag
if: ${{ env.RELEASE_REQUIRED == 'true' }}
+ env:+ RELEASE_TAG: ${{ env.RELEASE_TAG }}+ RELEASE_TAG_EXISTS: ${{ env.RELEASE_TAG_EXISTS }}
run: |
- if [ "${{ env.RELEASE_TAG_EXISTS }}" = false ]; then- git tag "${{ env.RELEASE_TAG }}"- git push origin "${{ env.RELEASE_TAG }}"+ if [ "$RELEASE_TAG_EXISTS" = false ]; then+ git tag "$RELEASE_TAG"+ git push origin "$RELEASE_TAG"
else
- echo "Tag ${{ env.RELEASE_TAG }} already exists"+ echo "Tag $RELEASE_TAG already exists"
fi

Also applies to: 304-306, 320-324, 329-331, 335-339, 344-350

🤖 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/npm-package-release.yml around lines 296 - 299, Move all
GitHub Actions expression expansions currently embedded in the run scripts
around the release commit, tag, publish, and packaging steps into step-level env
entries. Update the affected shell commands to reference those environment
variables instead, including values derived from RAINDEX_NEW_VERSION,
UC_NEW_VERSION, and npm pack output, while preserving the existing release
behavior.

Source: Linters/SAST tools

🤖 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/npm-package-release.yml:
- Around line 181-196: Update resolve_baseline_version to determine the highest
published semver rather than relying on npm view "$package_name@latest" version.
Compare the maximum registry version against repository_version and return the
higher baseline, preserving the repository fallback when no published versions
are available.
- Around line 198-224: Update the RAINDEX publish decision flow around
package_hash and the prerelease npm version step to verify each generated alpha
candidate with npm before publishing. After npm version prerelease selects a
candidate, query npm for that exact package version and continue incrementing
until the candidate is unused, while preserving the existing hash comparison and
publish behavior.
---
Nitpick comments:
In @.github/workflows/npm-package-release.yml:
- Around line 352-357: Update the Create GitHub Release step’s if condition to
require both RELEASE_REQUIRED to be true and GITHUB_RELEASE_EXISTS to indicate
that no release already exists. Preserve the existing tarball production
condition and release configuration.
- Around line 296-299: Move all GitHub Actions expression expansions currently
embedded in the run scripts around the release commit, tag, publish, and
packaging steps into step-level env entries. Update the affected shell commands
to reference those environment variables instead, including values derived from
RAINDEX_NEW_VERSION, UC_NEW_VERSION, and npm pack output, while preserving the
existing release behavior.
🪄 Autofix

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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fd2e4f2a-6844-4a5f-b4fe-ac246867df8b

📥 Commits

Reviewing files that changed from the base of the PR and between 16049a3 and df1fd1b.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml

Comment thread.github/workflows/npm-package-release.yml Outdated
Comment thread.github/workflows/npm-package-release.yml
@findolorfindolor self-assigned this Aug 12, 2026
@findolor
findolor requested a review from rouzweltAugust 13, 2026 11:26
@rouzwelt

Copy link
Copy Markdown
Contributor

@CodeRabbit review

@coderabbitai

coderabbitaiBot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor
⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@findolor
findolor merged commit 669d227 into mainAug 18, 2026
17 of 18 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bashset -euo pipefail
base="$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main)"printf'%s\n''--- base-to-HEAD diff stat ---'
git diff --stat "$base"...HEAD
printf'%s\n''--- changed files ---'
git diff --name-status "$base"...HEAD
printf'%s\n''--- workflow outline ---'
ast-grep outline .github/workflows/npm-package-release.yml --items all 2>/dev/null ||trueprintf'%s\n''--- workflow diff ---'
git diff --unified=20 "$base"...HEAD -- .github/workflows/npm-package-release.yml

Length of output: 22162


SIZE=L

You are interacting with an AI system.

Sign up for freeto 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.

2 participants

@findolor@rouzwelt
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Fix npm release recovery - #2830

Merged
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery
Aug 18, 2026
Merged

Fix npm release recovery#2830
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery

Conversation

@findolor

@findolorfindolor commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Motivation

The npm release workflow can leave Git and npm permanently out of sync. Run 31486644553 published raindex 0.0.1-alpha.244 and UI components 0.0.1-alpha.243, then failed to push its version commit because main advanced. Run 31487015421 consequently derived raindex 0.0.1-alpha.244 from the stale manifest and npm rejected the duplicate version.

This is not isolated to one run: #2815 previously had to synchronize package manifests after another partial two-package release.

Solution

  • Serialize npm release runs and skip a source commit once a newer main head supersedes it.
  • Reconcile each workspace independently against npm versions and exact tarball hashes before selecting a release version.
  • Preserve a Git-reserved version when npm is behind, adopt npm when the registry is ahead, and bump only when the selected published artifact differs.
  • Commit and push version reservations before changing npm, so a non-fast-forward failure cannot leave npm ahead of Git.
  • Allow the version-commit workflow run to recover automatically when neither, one, or both package publishes completed.
  • Publish only packages whose selected artifact is missing, while still rebuilding both release assets.
  • Create the tag only after required publishes succeed and recover a missing tag or GitHub release without republishing immutable versions.

Checks

  • nix run nixpkgs#actionlint -- .github/workflows/npm-package-release.yml
  • npx --no-install prettier --check .github/workflows/npm-package-release.yml
  • git diff --check
  • Simulated the live npm-ahead state: repository .243/.242, npm .244/.243; selected .245/.244.
  • Simulated a retry after committing .245/.244 with npm still behind; preserved both reserved versions without another bump.
  • Commit hooks passed, including no-consumer-prettier and yamlfmt.

Summary by CodeRabbit

  • Improvements
    • Release runs are now coordinated to prevent overlapping releases.
    • Release state is validated before publishing begins.
    • Package changes are detected more accurately before publishing.
    • Version updates are reserved before publication to reduce conflicting releases.
    • Release workflows can recover from partially completed runs.
    • Tags and release records are created only after successful package publication.
    • Unchanged packages can skip unnecessary versioning and publishing.

@coderabbitai

coderabbitaiBot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Important

Review skipped

No new commits to review since the last review.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0a99107c-a5fe-417f-9e2f-ee817011e8fd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ef8924e6-0084-406e-b5d5-5cd62b6b8a64

📥 Commits

Reviewing files that changed from the base of the PR and between df1fd1b and 4b9521e.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/npm-package-release.yml

📝 Walkthrough

Walkthrough

The npm release workflow now serializes runs, validates the current main head, reconciles package and registry state, commits required versions before publishing, and creates tags and GitHub releases after successful publication.

Changes

npm Release Workflow

Layer / File(s)Summary
Run serialization and head validation
.github/workflows/npm-package-release.yml
Concurrent release runs are serialized. The workflow identifies superseded commits and skips later release actions for them.
Package release-state reconciliation
.github/workflows/npm-package-release.yml
The workflow compares repository and npm package versions and tarball hashes. It handles first publishes, prerelease selection, dependency and lockfile updates, package-specific publish flags, and existing release state.
Version reservation and package publishing
.github/workflows/npm-package-release.yml
The workflow commits required package and lockfile version reservations before publishing. Tarball creation and publication use package-specific release flags.
Post-publish tag and GitHub release
.github/workflows/npm-package-release.yml
The workflow creates release tags after successful publication. It retains existing tags and creates GitHub releases only when required and absent.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
participant GitHubActions
participant MainBranch
participant NpmRegistry
participant GitHub
GitHubActions->>MainBranch: validate current main head
GitHubActions->>NpmRegistry: resolve package versions and tarball hashes
NpmRegistry-->>GitHubActions: return registry state
GitHubActions->>MainBranch: commit required version reservations
GitHubActions->>NpmRegistry: publish selected package tarballs
GitHubActions->>GitHub: create release tag after publishing
GitHubActions->>GitHub: create GitHub release when required
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check nameStatusExplanation
Docstring Coverage✅ PassedNo functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check✅ PassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes check✅ PassedCheck skipped because no linked issues were found for this pull request.
Description Check✅ PassedCheck skipped - CodeRabbit’s high-level summary is enabled.
Title check✅ PassedThe title clearly and concisely identifies the main change: improving npm release recovery.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch arda/fix-npm-release-recovery

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

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

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
.github/workflows/npm-package-release.yml (2)

352-357: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Create GitHub Release runs even when the release already exists.

The step condition uses only RELEASE_REQUIRED. GITHUB_RELEASE_EXISTS is computed at line 265 but never used in a step condition. softprops/action-gh-release@v2 updates an existing release by default, so this is not a failure, but it re-uploads the tarball assets on every recovery run. Gate the step on the existing-release state if you want the recovery path to be a no-op.

Note also that the tarball assets at lines 360-361 are only produced when RELEASE_REQUIRED is true, which matches this condition.

🤖 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/npm-package-release.yml around lines 352 - 357, Update the
Create GitHub Release step’s if condition to require both RELEASE_REQUIRED to be
true and GITHUB_RELEASE_EXISTS to indicate that no release already exists.
Preserve the existing tarball production condition and release configuration.

296-299: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value

Move ${{ ... }} expansions into env: blocks to satisfy zizmor.

zizmor flags template expansion inside run: bodies at lines 298, 306, 321, 331, 336, and 345-349. The values come from this workflow's own step, so the practical risk is low. The values still originate from repository files (package.json versions) and from npm pack output. Referencing them as shell variables removes the injection surface and clears the warnings.

♻️ Example for the tag step
 - name: Push release tag
if: ${{ env.RELEASE_REQUIRED == 'true' }}
+ env:+ RELEASE_TAG: ${{ env.RELEASE_TAG }}+ RELEASE_TAG_EXISTS: ${{ env.RELEASE_TAG_EXISTS }}
run: |
- if [ "${{ env.RELEASE_TAG_EXISTS }}" = false ]; then- git tag "${{ env.RELEASE_TAG }}"- git push origin "${{ env.RELEASE_TAG }}"+ if [ "$RELEASE_TAG_EXISTS" = false ]; then+ git tag "$RELEASE_TAG"+ git push origin "$RELEASE_TAG"
else
- echo "Tag ${{ env.RELEASE_TAG }} already exists"+ echo "Tag $RELEASE_TAG already exists"
fi

Also applies to: 304-306, 320-324, 329-331, 335-339, 344-350

🤖 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/npm-package-release.yml around lines 296 - 299, Move all
GitHub Actions expression expansions currently embedded in the run scripts
around the release commit, tag, publish, and packaging steps into step-level env
entries. Update the affected shell commands to reference those environment
variables instead, including values derived from RAINDEX_NEW_VERSION,
UC_NEW_VERSION, and npm pack output, while preserving the existing release
behavior.

Source: Linters/SAST tools

🤖 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/npm-package-release.yml:
- Around line 181-196: Update resolve_baseline_version to determine the highest
published semver rather than relying on npm view "$package_name@latest" version.
Compare the maximum registry version against repository_version and return the
higher baseline, preserving the repository fallback when no published versions
are available.
- Around line 198-224: Update the RAINDEX publish decision flow around
package_hash and the prerelease npm version step to verify each generated alpha
candidate with npm before publishing. After npm version prerelease selects a
candidate, query npm for that exact package version and continue incrementing
until the candidate is unused, while preserving the existing hash comparison and
publish behavior.
---
Nitpick comments:
In @.github/workflows/npm-package-release.yml:
- Around line 352-357: Update the Create GitHub Release step’s if condition to
require both RELEASE_REQUIRED to be true and GITHUB_RELEASE_EXISTS to indicate
that no release already exists. Preserve the existing tarball production
condition and release configuration.
- Around line 296-299: Move all GitHub Actions expression expansions currently
embedded in the run scripts around the release commit, tag, publish, and
packaging steps into step-level env entries. Update the affected shell commands
to reference those environment variables instead, including values derived from
RAINDEX_NEW_VERSION, UC_NEW_VERSION, and npm pack output, while preserving the
existing release behavior.
🪄 Autofix

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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fd2e4f2a-6844-4a5f-b4fe-ac246867df8b

📥 Commits

Reviewing files that changed from the base of the PR and between 16049a3 and df1fd1b.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml

Comment thread.github/workflows/npm-package-release.yml Outdated
Comment thread.github/workflows/npm-package-release.yml
@findolorfindolor self-assigned this Aug 12, 2026
@findolor
findolor requested a review from rouzweltAugust 13, 2026 11:26
@rouzwelt

Copy link
Copy Markdown
Contributor

@CodeRabbit review

@coderabbitai

coderabbitaiBot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor
⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@findolor
findolor merged commit 669d227 into mainAug 18, 2026
17 of 18 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bashset -euo pipefail
base="$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main)"printf'%s\n''--- base-to-HEAD diff stat ---'
git diff --stat "$base"...HEAD
printf'%s\n''--- changed files ---'
git diff --name-status "$base"...HEAD
printf'%s\n''--- workflow outline ---'
ast-grep outline .github/workflows/npm-package-release.yml --items all 2>/dev/null ||trueprintf'%s\n''--- workflow diff ---'
git diff --unified=20 "$base"...HEAD -- .github/workflows/npm-package-release.yml

Length of output: 22162


SIZE=L

You are interacting with an AI system.

Sign up for freeto 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.

2 participants

@findolor@rouzwelt
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Fix npm release recovery - #2830

Merged
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery
Aug 18, 2026
Merged

Fix npm release recovery#2830
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery

Conversation

@findolor

@findolorfindolor commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Motivation

The npm release workflow can leave Git and npm permanently out of sync. Run 31486644553 published raindex 0.0.1-alpha.244 and UI components 0.0.1-alpha.243, then failed to push its version commit because main advanced. Run 31487015421 consequently derived raindex 0.0.1-alpha.244 from the stale manifest and npm rejected the duplicate version.

This is not isolated to one run: #2815 previously had to synchronize package manifests after another partial two-package release.

Solution

  • Serialize npm release runs and skip a source commit once a newer main head supersedes it.
  • Reconcile each workspace independently against npm versions and exact tarball hashes before selecting a release version.
  • Preserve a Git-reserved version when npm is behind, adopt npm when the registry is ahead, and bump only when the selected published artifact differs.
  • Commit and push version reservations before changing npm, so a non-fast-forward failure cannot leave npm ahead of Git.
  • Allow the version-commit workflow run to recover automatically when neither, one, or both package publishes completed.
  • Publish only packages whose selected artifact is missing, while still rebuilding both release assets.
  • Create the tag only after required publishes succeed and recover a missing tag or GitHub release without republishing immutable versions.

Checks

  • nix run nixpkgs#actionlint -- .github/workflows/npm-package-release.yml
  • npx --no-install prettier --check .github/workflows/npm-package-release.yml
  • git diff --check
  • Simulated the live npm-ahead state: repository .243/.242, npm .244/.243; selected .245/.244.
  • Simulated a retry after committing .245/.244 with npm still behind; preserved both reserved versions without another bump.
  • Commit hooks passed, including no-consumer-prettier and yamlfmt.

Summary by CodeRabbit

  • Improvements
    • Release runs are now coordinated to prevent overlapping releases.
    • Release state is validated before publishing begins.
    • Package changes are detected more accurately before publishing.
    • Version updates are reserved before publication to reduce conflicting releases.
    • Release workflows can recover from partially completed runs.
    • Tags and release records are created only after successful package publication.
    • Unchanged packages can skip unnecessary versioning and publishing.

@coderabbitai

coderabbitaiBot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Important

Review skipped

No new commits to review since the last review.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0a99107c-a5fe-417f-9e2f-ee817011e8fd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ef8924e6-0084-406e-b5d5-5cd62b6b8a64

📥 Commits

Reviewing files that changed from the base of the PR and between df1fd1b and 4b9521e.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/npm-package-release.yml

📝 Walkthrough

Walkthrough

The npm release workflow now serializes runs, validates the current main head, reconciles package and registry state, commits required versions before publishing, and creates tags and GitHub releases after successful publication.

Changes

npm Release Workflow

Layer / File(s)Summary
Run serialization and head validation
.github/workflows/npm-package-release.yml
Concurrent release runs are serialized. The workflow identifies superseded commits and skips later release actions for them.
Package release-state reconciliation
.github/workflows/npm-package-release.yml
The workflow compares repository and npm package versions and tarball hashes. It handles first publishes, prerelease selection, dependency and lockfile updates, package-specific publish flags, and existing release state.
Version reservation and package publishing
.github/workflows/npm-package-release.yml
The workflow commits required package and lockfile version reservations before publishing. Tarball creation and publication use package-specific release flags.
Post-publish tag and GitHub release
.github/workflows/npm-package-release.yml
The workflow creates release tags after successful publication. It retains existing tags and creates GitHub releases only when required and absent.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
participant GitHubActions
participant MainBranch
participant NpmRegistry
participant GitHub
GitHubActions->>MainBranch: validate current main head
GitHubActions->>NpmRegistry: resolve package versions and tarball hashes
NpmRegistry-->>GitHubActions: return registry state
GitHubActions->>MainBranch: commit required version reservations
GitHubActions->>NpmRegistry: publish selected package tarballs
GitHubActions->>GitHub: create release tag after publishing
GitHubActions->>GitHub: create GitHub release when required
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check nameStatusExplanation
Docstring Coverage✅ PassedNo functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check✅ PassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes check✅ PassedCheck skipped because no linked issues were found for this pull request.
Description Check✅ PassedCheck skipped - CodeRabbit’s high-level summary is enabled.
Title check✅ PassedThe title clearly and concisely identifies the main change: improving npm release recovery.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch arda/fix-npm-release-recovery

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

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

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
.github/workflows/npm-package-release.yml (2)

352-357: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Create GitHub Release runs even when the release already exists.

The step condition uses only RELEASE_REQUIRED. GITHUB_RELEASE_EXISTS is computed at line 265 but never used in a step condition. softprops/action-gh-release@v2 updates an existing release by default, so this is not a failure, but it re-uploads the tarball assets on every recovery run. Gate the step on the existing-release state if you want the recovery path to be a no-op.

Note also that the tarball assets at lines 360-361 are only produced when RELEASE_REQUIRED is true, which matches this condition.

🤖 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/npm-package-release.yml around lines 352 - 357, Update the
Create GitHub Release step’s if condition to require both RELEASE_REQUIRED to be
true and GITHUB_RELEASE_EXISTS to indicate that no release already exists.
Preserve the existing tarball production condition and release configuration.

296-299: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value

Move ${{ ... }} expansions into env: blocks to satisfy zizmor.

zizmor flags template expansion inside run: bodies at lines 298, 306, 321, 331, 336, and 345-349. The values come from this workflow's own step, so the practical risk is low. The values still originate from repository files (package.json versions) and from npm pack output. Referencing them as shell variables removes the injection surface and clears the warnings.

♻️ Example for the tag step
 - name: Push release tag
if: ${{ env.RELEASE_REQUIRED == 'true' }}
+ env:+ RELEASE_TAG: ${{ env.RELEASE_TAG }}+ RELEASE_TAG_EXISTS: ${{ env.RELEASE_TAG_EXISTS }}
run: |
- if [ "${{ env.RELEASE_TAG_EXISTS }}" = false ]; then- git tag "${{ env.RELEASE_TAG }}"- git push origin "${{ env.RELEASE_TAG }}"+ if [ "$RELEASE_TAG_EXISTS" = false ]; then+ git tag "$RELEASE_TAG"+ git push origin "$RELEASE_TAG"
else
- echo "Tag ${{ env.RELEASE_TAG }} already exists"+ echo "Tag $RELEASE_TAG already exists"
fi

Also applies to: 304-306, 320-324, 329-331, 335-339, 344-350

🤖 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/npm-package-release.yml around lines 296 - 299, Move all
GitHub Actions expression expansions currently embedded in the run scripts
around the release commit, tag, publish, and packaging steps into step-level env
entries. Update the affected shell commands to reference those environment
variables instead, including values derived from RAINDEX_NEW_VERSION,
UC_NEW_VERSION, and npm pack output, while preserving the existing release
behavior.

Source: Linters/SAST tools

🤖 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/npm-package-release.yml:
- Around line 181-196: Update resolve_baseline_version to determine the highest
published semver rather than relying on npm view "$package_name@latest" version.
Compare the maximum registry version against repository_version and return the
higher baseline, preserving the repository fallback when no published versions
are available.
- Around line 198-224: Update the RAINDEX publish decision flow around
package_hash and the prerelease npm version step to verify each generated alpha
candidate with npm before publishing. After npm version prerelease selects a
candidate, query npm for that exact package version and continue incrementing
until the candidate is unused, while preserving the existing hash comparison and
publish behavior.
---
Nitpick comments:
In @.github/workflows/npm-package-release.yml:
- Around line 352-357: Update the Create GitHub Release step’s if condition to
require both RELEASE_REQUIRED to be true and GITHUB_RELEASE_EXISTS to indicate
that no release already exists. Preserve the existing tarball production
condition and release configuration.
- Around line 296-299: Move all GitHub Actions expression expansions currently
embedded in the run scripts around the release commit, tag, publish, and
packaging steps into step-level env entries. Update the affected shell commands
to reference those environment variables instead, including values derived from
RAINDEX_NEW_VERSION, UC_NEW_VERSION, and npm pack output, while preserving the
existing release behavior.
🪄 Autofix

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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fd2e4f2a-6844-4a5f-b4fe-ac246867df8b

📥 Commits

Reviewing files that changed from the base of the PR and between 16049a3 and df1fd1b.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml

Comment thread.github/workflows/npm-package-release.yml Outdated
Comment thread.github/workflows/npm-package-release.yml
@findolorfindolor self-assigned this Aug 12, 2026
@findolor
findolor requested a review from rouzweltAugust 13, 2026 11:26
@rouzwelt

Copy link
Copy Markdown
Contributor

@CodeRabbit review

@coderabbitai

coderabbitaiBot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor
⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@findolor
findolor merged commit 669d227 into mainAug 18, 2026
17 of 18 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bashset -euo pipefail
base="$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main)"printf'%s\n''--- base-to-HEAD diff stat ---'
git diff --stat "$base"...HEAD
printf'%s\n''--- changed files ---'
git diff --name-status "$base"...HEAD
printf'%s\n''--- workflow outline ---'
ast-grep outline .github/workflows/npm-package-release.yml --items all 2>/dev/null ||trueprintf'%s\n''--- workflow diff ---'
git diff --unified=20 "$base"...HEAD -- .github/workflows/npm-package-release.yml

Length of output: 22162


SIZE=L

You are interacting with an AI system.

Sign up for freeto 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.

2 participants

@findolor@rouzwelt
, 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Fix npm release recovery - #2830

Merged
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery
Aug 18, 2026
Merged

Fix npm release recovery#2830
findolor merged 2 commits into
mainfrom
arda/fix-npm-release-recovery

Conversation

@findolor

@findolorfindolor commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

Motivation

The npm release workflow can leave Git and npm permanently out of sync. Run 31486644553 published raindex 0.0.1-alpha.244 and UI components 0.0.1-alpha.243, then failed to push its version commit because main advanced. Run 31487015421 consequently derived raindex 0.0.1-alpha.244 from the stale manifest and npm rejected the duplicate version.

This is not isolated to one run: #2815 previously had to synchronize package manifests after another partial two-package release.

Solution

  • Serialize npm release runs and skip a source commit once a newer main head supersedes it.
  • Reconcile each workspace independently against npm versions and exact tarball hashes before selecting a release version.
  • Preserve a Git-reserved version when npm is behind, adopt npm when the registry is ahead, and bump only when the selected published artifact differs.
  • Commit and push version reservations before changing npm, so a non-fast-forward failure cannot leave npm ahead of Git.
  • Allow the version-commit workflow run to recover automatically when neither, one, or both package publishes completed.
  • Publish only packages whose selected artifact is missing, while still rebuilding both release assets.
  • Create the tag only after required publishes succeed and recover a missing tag or GitHub release without republishing immutable versions.

Checks

  • nix run nixpkgs#actionlint -- .github/workflows/npm-package-release.yml
  • npx --no-install prettier --check .github/workflows/npm-package-release.yml
  • git diff --check
  • Simulated the live npm-ahead state: repository .243/.242, npm .244/.243; selected .245/.244.
  • Simulated a retry after committing .245/.244 with npm still behind; preserved both reserved versions without another bump.
  • Commit hooks passed, including no-consumer-prettier and yamlfmt.

Summary by CodeRabbit

  • Improvements
    • Release runs are now coordinated to prevent overlapping releases.
    • Release state is validated before publishing begins.
    • Package changes are detected more accurately before publishing.
    • Version updates are reserved before publication to reduce conflicting releases.
    • Release workflows can recover from partially completed runs.
    • Tags and release records are created only after successful package publication.
    • Unchanged packages can skip unnecessary versioning and publishing.

@coderabbitai

coderabbitaiBot commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Important

Review skipped

No new commits to review since the last review.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 0a99107c-a5fe-417f-9e2f-ee817011e8fd

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ef8924e6-0084-406e-b5d5-5cd62b6b8a64

📥 Commits

Reviewing files that changed from the base of the PR and between df1fd1b and 4b9521e.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • .github/workflows/npm-package-release.yml

📝 Walkthrough

Walkthrough

The npm release workflow now serializes runs, validates the current main head, reconciles package and registry state, commits required versions before publishing, and creates tags and GitHub releases after successful publication.

Changes

npm Release Workflow

Layer / File(s)Summary
Run serialization and head validation
.github/workflows/npm-package-release.yml
Concurrent release runs are serialized. The workflow identifies superseded commits and skips later release actions for them.
Package release-state reconciliation
.github/workflows/npm-package-release.yml
The workflow compares repository and npm package versions and tarball hashes. It handles first publishes, prerelease selection, dependency and lockfile updates, package-specific publish flags, and existing release state.
Version reservation and package publishing
.github/workflows/npm-package-release.yml
The workflow commits required package and lockfile version reservations before publishing. Tarball creation and publication use package-specific release flags.
Post-publish tag and GitHub release
.github/workflows/npm-package-release.yml
The workflow creates release tags after successful publication. It retains existing tags and creates GitHub releases only when required and absent.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
participant GitHubActions
participant MainBranch
participant NpmRegistry
participant GitHub
GitHubActions->>MainBranch: validate current main head
GitHubActions->>NpmRegistry: resolve package versions and tarball hashes
NpmRegistry-->>GitHubActions: return registry state
GitHubActions->>MainBranch: commit required version reservations
GitHubActions->>NpmRegistry: publish selected package tarballs
GitHubActions->>GitHub: create release tag after publishing
GitHubActions->>GitHub: create GitHub release when required
Loading
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check nameStatusExplanation
Docstring Coverage✅ PassedNo functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check✅ PassedCheck skipped because no linked issues were found for this pull request.
Out of Scope Changes check✅ PassedCheck skipped because no linked issues were found for this pull request.
Description Check✅ PassedCheck skipped - CodeRabbit’s high-level summary is enabled.
Title check✅ PassedThe title clearly and concisely identifies the main change: improving npm release recovery.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch arda/fix-npm-release-recovery

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

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

@coderabbitaicoderabbitaiBot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
.github/workflows/npm-package-release.yml (2)

352-357: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Create GitHub Release runs even when the release already exists.

The step condition uses only RELEASE_REQUIRED. GITHUB_RELEASE_EXISTS is computed at line 265 but never used in a step condition. softprops/action-gh-release@v2 updates an existing release by default, so this is not a failure, but it re-uploads the tarball assets on every recovery run. Gate the step on the existing-release state if you want the recovery path to be a no-op.

Note also that the tarball assets at lines 360-361 are only produced when RELEASE_REQUIRED is true, which matches this condition.

🤖 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/npm-package-release.yml around lines 352 - 357, Update the
Create GitHub Release step’s if condition to require both RELEASE_REQUIRED to be
true and GITHUB_RELEASE_EXISTS to indicate that no release already exists.
Preserve the existing tarball production condition and release configuration.

296-299: 🔒 Security & Privacy | 🔵 Trivial | 💤 Low value

Move ${{ ... }} expansions into env: blocks to satisfy zizmor.

zizmor flags template expansion inside run: bodies at lines 298, 306, 321, 331, 336, and 345-349. The values come from this workflow's own step, so the practical risk is low. The values still originate from repository files (package.json versions) and from npm pack output. Referencing them as shell variables removes the injection surface and clears the warnings.

♻️ Example for the tag step
 - name: Push release tag
if: ${{ env.RELEASE_REQUIRED == 'true' }}
+ env:+ RELEASE_TAG: ${{ env.RELEASE_TAG }}+ RELEASE_TAG_EXISTS: ${{ env.RELEASE_TAG_EXISTS }}
run: |
- if [ "${{ env.RELEASE_TAG_EXISTS }}" = false ]; then- git tag "${{ env.RELEASE_TAG }}"- git push origin "${{ env.RELEASE_TAG }}"+ if [ "$RELEASE_TAG_EXISTS" = false ]; then+ git tag "$RELEASE_TAG"+ git push origin "$RELEASE_TAG"
else
- echo "Tag ${{ env.RELEASE_TAG }} already exists"+ echo "Tag $RELEASE_TAG already exists"
fi

Also applies to: 304-306, 320-324, 329-331, 335-339, 344-350

🤖 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/npm-package-release.yml around lines 296 - 299, Move all
GitHub Actions expression expansions currently embedded in the run scripts
around the release commit, tag, publish, and packaging steps into step-level env
entries. Update the affected shell commands to reference those environment
variables instead, including values derived from RAINDEX_NEW_VERSION,
UC_NEW_VERSION, and npm pack output, while preserving the existing release
behavior.

Source: Linters/SAST tools

🤖 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/npm-package-release.yml:
- Around line 181-196: Update resolve_baseline_version to determine the highest
published semver rather than relying on npm view "$package_name@latest" version.
Compare the maximum registry version against repository_version and return the
higher baseline, preserving the repository fallback when no published versions
are available.
- Around line 198-224: Update the RAINDEX publish decision flow around
package_hash and the prerelease npm version step to verify each generated alpha
candidate with npm before publishing. After npm version prerelease selects a
candidate, query npm for that exact package version and continue incrementing
until the candidate is unused, while preserving the existing hash comparison and
publish behavior.
---
Nitpick comments:
In @.github/workflows/npm-package-release.yml:
- Around line 352-357: Update the Create GitHub Release step’s if condition to
require both RELEASE_REQUIRED to be true and GITHUB_RELEASE_EXISTS to indicate
that no release already exists. Preserve the existing tarball production
condition and release configuration.
- Around line 296-299: Move all GitHub Actions expression expansions currently
embedded in the run scripts around the release commit, tag, publish, and
packaging steps into step-level env entries. Update the affected shell commands
to reference those environment variables instead, including values derived from
RAINDEX_NEW_VERSION, UC_NEW_VERSION, and npm pack output, while preserving the
existing release behavior.
🪄 Autofix

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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: fd2e4f2a-6844-4a5f-b4fe-ac246867df8b

📥 Commits

Reviewing files that changed from the base of the PR and between 16049a3 and df1fd1b.

📒 Files selected for processing (1)
  • .github/workflows/npm-package-release.yml

Comment thread.github/workflows/npm-package-release.yml Outdated
Comment thread.github/workflows/npm-package-release.yml
@findolorfindolor self-assigned this Aug 12, 2026
@findolor
findolor requested a review from rouzweltAugust 13, 2026 11:26
@rouzwelt

Copy link
Copy Markdown
Contributor

@CodeRabbit review

@coderabbitai

coderabbitaiBot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor
⚠️ Action not completed

Already reviewed.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@findolor
findolor merged commit 669d227 into mainAug 18, 2026
17 of 18 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

@coderabbitai assess this PR size classification for the totality of the PR with the following criterias and report it in your comment:

S/M/L PR Classification Guidelines:

This guide helps classify merged pull requests by effort and complexity rather than just line count. The goal is to assess the difficulty and scope of changes after they have been completed.

Small (S)

Characteristics:

  • Simple bug fixes, typos, or minor refactoring
  • Single-purpose changes affecting 1-2 files
  • Documentation updates
  • Configuration tweaks
  • Changes that require minimal context to review

Review Effort: Would have taken 5-10 minutes

Examples:

  • Fix typo in variable name
  • Update README with new instructions
  • Adjust configuration values
  • Simple one-line bug fixes
  • Import statement cleanup

Medium (M)

Characteristics:

  • Feature additions or enhancements
  • Refactoring that touches multiple files but maintains existing behavior
  • Breaking changes with backward compatibility
  • Changes requiring some domain knowledge to review

Review Effort: Would have taken 15-30 minutes

Examples:

  • Add new feature or component
  • Refactor common utility functions
  • Update dependencies with minor breaking changes
  • Add new component with tests
  • Performance optimizations
  • More complex bug fixes

Large (L)

Characteristics:

  • Major feature implementations
  • Breaking changes or API redesigns
  • Complex refactoring across multiple modules
  • New architectural patterns or significant design changes
  • Changes requiring deep context and multiple review rounds

Review Effort: Would have taken 45+ minutes

Examples:

  • Complete new feature with frontend/backend changes
  • Protocol upgrades or breaking changes
  • Major architectural refactoring
  • Framework or technology upgrades

Additional Factors to Consider

When deciding between sizes, also consider:

  • Test coverage impact: More comprehensive test changes lean toward larger classification
  • Risk level: Changes to critical systems bump up a size category
  • Team familiarity: Novel patterns or technologies increase complexity

Notes:

  • the assessment must be for the totality of the PR, that means comparing the base branch to the last commit of the PR
  • the assessment output must be exactly one of: S, M or L (single-line comment) in format of: SIZE={S/M/L}
  • do not include any additional text, only the size classification
  • your assessment comment must not include tips or additional sections
  • do NOT tag me or anyone else on your comment

@coderabbitai

Copy link
Copy Markdown
Contributor

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bashset -euo pipefail
base="$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main)"printf'%s\n''--- base-to-HEAD diff stat ---'
git diff --stat "$base"...HEAD
printf'%s\n''--- changed files ---'
git diff --name-status "$base"...HEAD
printf'%s\n''--- workflow outline ---'
ast-grep outline .github/workflows/npm-package-release.yml --items all 2>/dev/null ||trueprintf'%s\n''--- workflow diff ---'
git diff --unified=20 "$base"...HEAD -- .github/workflows/npm-package-release.yml

Length of output: 22162


SIZE=L

You are interacting with an AI system.

Sign up for freeto 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.

2 participants

@findolor@rouzwelt