Skip to content

build: bump RUSTC_VERSION to 1.88 in github workflows - #65742

Open
joyeecheung wants to merge 1 commit into
nodejs:mainfrom
joyeecheung:fix-canary-rust
Open

build: bump RUSTC_VERSION to 1.88 in github workflows#65742
joyeecheung wants to merge 1 commit into
nodejs:mainfrom
joyeecheung:fix-canary-rust

Conversation

@joyeecheung

@joyeecheung joyeecheung commented Sep 2, 2026

Copy link
Copy Markdown
Member

The canary builds have been failing:

error: rustc 1.86.0 is not supported by the following packages:
  diplomat@0.16.1 requires rustc 1.88
  diplomat-runtime@0.15.2 requires rustc 1.88
  diplomat_core@0.16.1 requires rustc 1.88
  icu_locale_core@2.3.0 requires rustc 1.88
  icu_provider@2.3.1 requires rustc 1.88
  node_crates@15.5.1 requires rustc 1.88

make[2]: *** [deps/crates/node_crates.target.mk:13: /home/runner/work/node-v8/node-v8/node/out/Release/obj/gen//release/libnode_crates.a] Error 101

This updates the github action files to keep the rust version in line with Jenkins nodejs/build#4265

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/actions

@nodejs-github-bot nodejs-github-bot added the meta Issues and PRs related to the general management of the project. label Sep 2, 2026
@joyeecheung
joyeecheung changed the base branch from canary-base to main September 2, 2026 11:48
@joyeecheung joyeecheung changed the title [canary-base] build: bump RUSTC_VERSION to 1.88 in github workflows build: bump RUSTC_VERSION to 1.88 in github workflows Sep 2, 2026
@joyeecheung joyeecheung added the fast-track PRs proposed for a shorter-than-standard waiting period before landing. label Sep 2, 2026
@github-actions

github-actions Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Fast-track has been requested by @joyeecheung. Please 👍 to approve.

Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
@joyeecheung

Copy link
Copy Markdown
Member Author

It looks like github actions didn't recognize my base branch change. Rebased. @richardlau @aduh95 can you take a look again?

@richardlau richardlau added dont-land-on-v22.x PRs that should not land on the v22.x-staging branch and should not be released in v22.x. dont-land-on-v24.x PRs that should not land on the v24.x-staging branch and should not be released in v24.x. labels Sep 2, 2026
@richardlau richardlau added the dont-land-on-v26.x PRs that should not land on the v26.x-staging branch and should not be released in v26.x. label Sep 2, 2026
@richardlau

richardlau commented Sep 2, 2026

Copy link
Copy Markdown
Member

(Given this is for canary, this should only be needed for future V8/temporal so I've also added dont-land-on-v26.x PRs that should not land on the v26.x-staging branch and should not be released in v26.x. .)

@MikeMcC399

Copy link
Copy Markdown
Contributor

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

@joyeecheung

Copy link
Copy Markdown
Member Author

Should the minimum version in https://github.com/nodejs/node/blob/main/BUILDING.md#building-nodejs-with-temporal-support be updated as well?

I think that will only become necessary after V8 15.3 lands? For now rust 1.86 still works with main, just won't be when 15.3 and above lands

@Renegade334

Copy link
Copy Markdown
Member

@joyeecheung if we are not planning on upgrading beyond V8 15.2 for v27.x, then would it not be prudent to keep testing on our advertised minimum rustc version, at least until #65161 lands? Could this commit be floated on canary until then?

@joyeecheung

Copy link
Copy Markdown
Member Author

I originally targeted this PR against canary-base until I realized that we have already finished then upgrade of rustc in Jenkins. If we have to choose I'd choose bumping the version in the documentation instead of continuing testing 1.86, though I prefer to leave that as a follow up, considering V8 is basically the sole factor here that decides the minimum rust version and I wouldn't worry too much about temporarily not testing the documented floor before another V8 upgrade on the main branch (I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build).

@Renegade334

Copy link
Copy Markdown
Member

I think we generally don't preemptively bump the clang/gcc/xcode version requirement documentation to the tested floor either, if the documented version is still known to build

Indeed, but we technically wouldn't know, as this would remove the last place where the documented version is tested to see whether or not it builds. It only really makes a difference for landing V8 majors as that's where the crates are updated, but given that we're still in the process of landing a major with an MSRV of 1.86, it feels like we could hold off until that lands?

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

Labels

dont-land-on-v22.x PRs that should not land on the v22.x-staging branch and should not be released in v22.x. dont-land-on-v24.x PRs that should not land on the v24.x-staging branch and should not be released in v24.x. dont-land-on-v26.x PRs that should not land on the v26.x-staging branch and should not be released in v26.x. fast-track PRs proposed for a shorter-than-standard waiting period before landing. meta Issues and PRs related to the general management of the project.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants