Add nodejs release actions#10
Conversation
|
Warning Review limit reached
More reviews will be available in 50 minutes and 57 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
WalkthroughThis PR introduces two complementary GitHub Actions reusable workflows for automating Node.js package releases. The Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 9
🧹 Nitpick comments (1)
.github/workflows/nodejs-publish-release.yml (1)
60-68: ⚖️ Poor tradeoffConsider pinning actions to SHA hashes for supply chain security.
The actions (
actions/checkout@v4,pnpm/action-setup@v4,actions/setup-node@v4,taiki-e/install-action@v2) use version tags. For stronger supply chain guarantees, consider pinning to full SHA hashes. This prevents issues if a tag is moved to a compromised commit.Example:
actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1Also applies to: 108-110
🤖 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/nodejs-publish-release.yml around lines 60 - 68, The workflow currently references third-party actions using floating tags (actions/checkout@v4, pnpm/action-setup@v4, actions/setup-node@v4, taiki-e/install-action@v2); replace each tag with the corresponding full commit SHA for that release (e.g., actions/checkout@<full-sha> with a comment indicating the tag like "# v4.x.y") to pin the exact commit and prevent future tag mutation, updating the usages for actions/checkout, pnpm/action-setup, actions/setup-node, and taiki-e/install-action wherever they appear in the file.
🤖 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/nodejs-prepare-release.yml:
- Line 60: Update the pinned git-cliff version string in the workflow by
replacing the current "tool: git-cliff@2.12.0" entry with "tool:
git-cliff@2.13.1" so the job uses the latest stable release; ensure the exact
YAML key/value is updated and commit the workflow change.
- Around line 92-95: In the "Generate changelog" step, avoid direct shell
expansion of the input cliff_config_url to prevent injection; validate the
cliff_config_url format (e.g., against an allowed-scheme/host pattern) and
export it as an environment variable (rather than interpolating into the run
line), then invoke git-cliff using that env var (keep RELEASE_VERSION env) so
the command becomes safe; ensure the step fails if validation fails and
reference the step name "Generate changelog", the input variable
cliff_config_url, and the git-cliff invocation when implementing the change.
- Around line 37-42: The current Validate inputs step directly expands `${{
inputs.package_manager }}` inside a shell case (in the Validate inputs step),
which can create a template injection vector; replace this by performing
validation via a GitHub Actions expression (e.g. use an `if: ${{
inputs.package_manager == 'npm' || inputs.package_manager == 'yarn' ||
inputs.package_manager == 'pnpm' }}` on a preceding step or job to allow
continuing, or use a conditional run that fails with `echo "::error::..." &&
exit 1` when the expression is false), and only after passing that expression
assign the safe value into an environment variable like `PACKAGE_MANAGER` for
subsequent shell usage; remove the direct `${{ inputs.package_manager }}`
expansion inside the shell case in the Validate inputs step and rely on the
validated env var instead.
- Around line 62-67: The step "Determine next version from commits" (id:
cliff-version) currently expands inputs.cliff_config_url directly into a shell
command for git-cliff --config-url, allowing shell injection; before running
git-cliff, validate inputs.cliff_config_url to ensure it matches an accepted URL
pattern (e.g., https?://... or a safe file:// path) and reject or fail the
workflow if it contains shell metacharacters or an unexpected scheme; implement
this validation as a small pre-check in the same run block (or a separate step)
that inspects the environment variable corresponding to inputs.cliff_config_url
and exits nonzero with a clear error if validation fails, then pass the
validated value into git-cliff --config-url.
- Around line 44-47: Replace loose GitHub Actions version tags with pinned
commit SHAs for reproducibility: update the uses entries actions/checkout@v4 →
actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5, pnpm/action-setup@v4
→ pnpm/action-setup@b906affcce14559ad1aafd4ab0e942779e9f58b1,
actions/setup-node@v4 →
actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020, and
taiki-e/install-action@v2 →
taiki-e/install-action@25435dc8dd3baed7417e0c96d3fe89013a5b2e09 in the workflow
file so each uses: reference points to the provided commit SHA instead of the
floating tag.
In @.github/workflows/nodejs-publish-release.yml:
- Around line 60-62: Update the actions/checkout@v4 step to set
persist-credentials: false so the GITHUB_TOKEN is not left in .git/config after
checkout; specifically, in the checkout action configuration where fetch-depth:
0 is defined (and you have contents: write permission), add persist-credentials:
false to prevent credential leakage.
- Around line 112-116: The workflow step "Generate release notes" currently
interpolates inputs.cliff_config_url directly into the shell command; export the
URL as an env var and reference that variable in the git-cliff invocation
instead. Add an env entry like CLIFF_CONFIG_URL: ${{ inputs.cliff_config_url }}
alongside RELEASE_VERSION, and change the command to use --config-url
"$CLIFF_CONFIG_URL" (preserving the existing --tag "v$RELEASE_VERSION" --latest
--strip all > release-notes.md). This keeps the step name "Generate release
notes" and the RELEASE_VERSION usage unchanged while avoiding unsafe shell
interpolation of the input.
- Around line 74-88: The "Build" step dangerously interpolates
inputs.build_script directly into shell commands, allowing shell injection;
change to pass inputs.build_script via an environment variable (e.g.,
BUILD_SCRIPT=${{ inputs.build_script }}) and reference it as a quoted variable
("$BUILD_SCRIPT") inside the case branches for package_manager (the same pattern
applies to any other interpolated inputs in the "Install dependencies"/"Build"
steps), and add simple validation/whitelist of BUILD_SCRIPT (allow only expected
script names or constrain to a safe regex like alphanumeric, hyphen/underscore)
before executing to prevent malicious payloads.
- Around line 53-58: The Validate inputs step is interpolating ${{
inputs.package_manager }} directly into the shell which can lead to command
injection; change it to pass the input via an environment variable (e.g.,
PACKAGE_MANAGER from inputs.package_manager) and then use the shell variable
inside the run script (quoted) when evaluating the case statement (replace
occurrences of the literal ${{ inputs.package_manager }} with
"$PACKAGE_MANAGER") so the shell handles the value safely.
---
Nitpick comments:
In @.github/workflows/nodejs-publish-release.yml:
- Around line 60-68: The workflow currently references third-party actions using
floating tags (actions/checkout@v4, pnpm/action-setup@v4, actions/setup-node@v4,
taiki-e/install-action@v2); replace each tag with the corresponding full commit
SHA for that release (e.g., actions/checkout@<full-sha> with a comment
indicating the tag like "# v4.x.y") to pin the exact commit and prevent future
tag mutation, updating the usages for actions/checkout, pnpm/action-setup,
actions/setup-node, and taiki-e/install-action wherever they appear in the file.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9a8bd586-6830-4a15-a2e1-85e187498d9a
📒 Files selected for processing (2)
.github/workflows/nodejs-prepare-release.yml.github/workflows/nodejs-publish-release.yml
8afffb2 to
06ed182
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/nodejs-prepare-release.yml:
- Around line 86-94: The "Bump package version" step currently expands ${{
inputs.package_manager }} inline inside the shell case, leaving a
template-injection pattern; set an environment variable PACKAGE_MANAGER from the
input (env: PACKAGE_MANAGER: ${{ inputs.package_manager }}) and update the case
to use "$PACKAGE_MANAGER" instead of the inline expansion, keeping the existing
RELEASE_VERSION usage and the three branches (yarn, pnpm, npm) in the run block.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fb776b6d-6c9b-4dd2-a9f1-4c680f588e9f
📒 Files selected for processing (4)
.github/workflows/changelog-preview-comment.yml.github/workflows/nodejs-prepare-release.yml.github/workflows/nodejs-publish-release.yml.github/workflows/prepare-release.yml
06ed182 to
6f937e4
Compare
Avoids re-generating with git-cliff and keeps any manual edits.
ce0ce77 to
5e6307e
Compare
|
✔️ 6cd0073...bf1cbf7 - Conventional commits check succeeded. |
As part of holochain/hc-spin#62, this PR adds reusable workflows for preparing and publishing releases automatically, along with generating changelogs from conventional commits using git-cliff. This follows the same idea as the the existing Rust release automation in this repo but avoids using the Holochain release-integration utility as that is designed for Rust projects.