Skip to content

build: update Node.js toolchain version to 24.18.0#17742

Open
diemol wants to merge 3 commits into
trunkfrom
bump-node-toolchain-npm-trusted-publishing
Open

build: update Node.js toolchain version to 24.18.0#17742
diemol wants to merge 3 commits into
trunkfrom
bump-node-toolchain-npm-trusted-publishing

Conversation

@diemol

@diemol diemol commented Jul 2, 2026

Copy link
Copy Markdown
Member

To do npm trusted publishing for Selenium's release workflow, The current version of Node pinned in toolchain in MODULE.bazel changes from 22.22.0 to 24.18.0 to get a compatible npm version.

@selenium-ci selenium-ci added the B-build Includes scripting, bazel and CI integrations label Jul 2, 2026
@qodo-code-review

Copy link
Copy Markdown
Contributor

PR Summary by Qodo

build: bump Bazel Node.js toolchain to 24.18.0 for npm trusted publishing

⚙️ Configuration changes ✨ Enhancement 🕐 Less than 5 minutes

Grey Divider

AI Description

• Bump the Bazel-pinned Node.js toolchain from 22.22.0 to 24.18.0.
• Unblock npm trusted publishing by ensuring a compatible npm version in release workflows.
Diagram

graph TD
  A["MODULE.bazel"] --> B["rules_nodejs toolchain"] --> C["npm / release workflow"]
  subgraph Legend
    direction LR
    _cfg["Config"] ~~~ _tool["Toolchain"] ~~~ _flow["Workflow"]
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Pin npm separately (keep Node 22)
  • ➕ Avoids a major Node version jump if other tooling depends on Node 22 behavior
  • ➕ Smaller surface-area change (npm-only)
  • ➖ Harder to do cleanly in Bazel toolchain flows; npm is typically coupled to Node distribution
  • ➖ May increase maintenance complexity and reduce reproducibility
2. Move publishing to a dedicated CI step with its own Node setup
  • ➕ Decouples build toolchain from release/publishing requirements
  • ➕ Lets publishing pick the minimal Node/npm version needed
  • ➖ Adds divergence between Bazel-managed toolchains and CI environment
  • ➖ More CI configuration and potential for drift

Recommendation: Bumping the Bazel-managed Node toolchain is the most straightforward way to ensure a compatible npm for trusted publishing while keeping builds reproducible. Consider a separate publishing-only Node setup only if the Node 24 bump causes downstream incompatibilities in build/test tooling.

Files changed (1) +1 / -1

Other (1) +1 / -1
MODULE.bazelUpdate rules_nodejs toolchain Node version to 24.18.0 +1/-1

Update rules_nodejs toolchain Node version to 24.18.0

• Bumps the pinned Node.js toolchain version from 22.22.0 to 24.18.0 to align npm behavior/version with trusted publishing needs.

MODULE.bazel

@qodo-code-review

qodo-code-review Bot commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
✅ Compliance rules (platform): 11 rules

Grey Divider


Action required

1. Skipped releases can fail 🐞 Bug ☼ Reliability
Description
The publish matrix always includes a javascript leg and the skip decision happens inside the
run script, but the new node-version value makes the reusable bazel.yml workflow run
actions/setup-node before that skip check. A transient setup-node failure can therefore fail the
publish job and block downstream release steps even when JavaScript publishing was intended to be
skipped.
Code

.github/workflows/release.yml[144]

+      node-version: ${{ matrix.language == 'javascript' && '24' || '' }}
Evidence
The publish job always includes javascript in its matrix and only skips JavaScript publishing
inside the provided run script. With the new node-version input, bazel.yml will run
actions/setup-node for the javascript matrix leg before executing that run script, meaning a
setup-node failure can fail the overall publish job; downstream github-release-publish
explicitly depends on publish.

.github/workflows/release.yml[129-157]
.github/workflows/release.yml[193-200]
.github/workflows/bazel.yml[150-154]
.github/workflows/bazel.yml[217-228]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`release.yml` passes a non-empty `node-version` for the `javascript` matrix entry unconditionally. In the reusable workflow (`bazel.yml`), this triggers the `Setup Node` step before the `run` script gets to decide whether to skip publishing for that matrix leg, so a failure in Node setup can fail the overall `publish` job even when JavaScript publishing should be skipped.

## Issue Context
- `publish` always runs a matrix including `javascript`, and only skips inside `run` based on `needs.parse-tag.outputs.language`.
- `bazel.yml` executes `actions/setup-node` whenever `inputs.node-version != ''`, and this happens before the step that runs `${{ inputs.run }}`.
- `github-release-publish` depends on `publish`, so a failing matrix leg can block downstream release work.

## Fix
Update the `node-version` expression to only set a non-empty value when BOTH:
1) `matrix.language == 'javascript'`, and
2) the parsed tag indicates `all` or `javascript`.

For example:
```yaml
node-version: ${{ (matrix.language == 'javascript' && (needs.parse-tag.outputs.language == 'all' || needs.parse-tag.outputs.language == 'javascript')) && '24' || '' }}
```

## Fix Focus Areas
- .github/workflows/release.yml[129-156]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Previous review results

Review updated until commit b6389be

Results up to commit c712c08


🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Qodo Logo

name: Publish ${{ matrix.language }}
gpg-sign: ${{ matrix.language == 'java' }}
gem-trusted-publishing: ${{ matrix.language == 'ruby' }}
node-version: ${{ matrix.language == 'javascript' && '24' || '' }}

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.

Action required

1. Skipped releases can fail 🐞 Bug ☼ Reliability

The publish matrix always includes a javascript leg and the skip decision happens inside the
run script, but the new node-version value makes the reusable bazel.yml workflow run
actions/setup-node before that skip check. A transient setup-node failure can therefore fail the
publish job and block downstream release steps even when JavaScript publishing was intended to be
skipped.
Agent Prompt
## Issue description
`release.yml` passes a non-empty `node-version` for the `javascript` matrix entry unconditionally. In the reusable workflow (`bazel.yml`), this triggers the `Setup Node` step before the `run` script gets to decide whether to skip publishing for that matrix leg, so a failure in Node setup can fail the overall `publish` job even when JavaScript publishing should be skipped.

## Issue Context
- `publish` always runs a matrix including `javascript`, and only skips inside `run` based on `needs.parse-tag.outputs.language`.
- `bazel.yml` executes `actions/setup-node` whenever `inputs.node-version != ''`, and this happens before the step that runs `${{ inputs.run }}`.
- `github-release-publish` depends on `publish`, so a failing matrix leg can block downstream release work.

## Fix
Update the `node-version` expression to only set a non-empty value when BOTH:
1) `matrix.language == 'javascript'`, and
2) the parsed tag indicates `all` or `javascript`.

For example:
```yaml
node-version: ${{ (matrix.language == 'javascript' && (needs.parse-tag.outputs.language == 'all' || needs.parse-tag.outputs.language == 'javascript')) && '24' || '' }}
```

## Fix Focus Areas
- .github/workflows/release.yml[129-156]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit b6389be

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

B-build Includes scripting, bazel and CI integrations

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants