You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
v8-canary builds missing since May 17, linux/darwin builds missing since Febrary #312
I believe the culprit is https://ci-release.nodejs.org/job/iojs+release-mefi-pgo/4/ (cc @StefanStojanovic ) which hasn't set a datestring field so it ends up reusing the target directory and promotion breaks because it cannot overwrite the now restricted directory. To fix this I'm going to removed the staged directory for v26.0.0-test5becfbc91f904c6bf93ca0098ce34694a1bb4aa3 so that the promote script doesn't try to overwrite the existing files.
@richardlau yes, it is my fault, and I apologize. One question: in the datestring description, it says Only needed for nightly, and I was using test builds. For future builds of this job (I plan to run some today), what should I do to prevent the issue I caused? Just add datestring?
@richardlau yes, it is my fault, and I apologize. One question: in the datestring description, it says Only needed for nightly, and I was using test builds. For future builds of this job (I plan to run some today), what should I do to prevent the issue I caused? Just add datestring?
Yes, setting the datestring would be the simplest way.
How recent is this? There is caching in place, so I would not expect a new canary to be available instantly?
That's fair, but then all the builds between 20260904 to today are missing on https://nodejs.org/download/v8-canary/ but are present on the DO droplet and R2 dist. i.e.
v27.0.0-v8-canary202609153f670614ec
v27.0.0-v8-canary20260916045505e938
v27.0.0-v8-canary20260917d5e7bad223
we didn't have any builds between 4 September and 15 September. The directory cache for the worker was manually refreshed on 7 September.
Activity
targos commentedon May 21, 2026
Currently the main issue is the Rust version requirement
richardlau commentedon May 21, 2026
We should be getting Linux builds now (I updated Rust on the RHEL 8 release machines (all archs)).
I'm suspicious that 20260517 is the last available downloadable build as we have in staging, e.g
which suggests something is going wrong with promotion for the canary builds.
richardlau commentedon May 21, 2026
This is the cause:
File cannot be removed because the target directory is old enough that it was made write only for the
distuser:I believe the culprit is https://ci-release.nodejs.org/job/iojs+release-mefi-pgo/4/ (cc @StefanStojanovic ) which hasn't set a datestring field so it ends up reusing the target directory and promotion breaks because it cannot overwrite the now restricted directory. To fix this I'm going to removed the staged directory for
v26.0.0-test5becfbc91f904c6bf93ca0098ce34694a1bb4aa3so that the promote script doesn't try to overwrite the existing files.richardlau commentedon May 21, 2026
https://nodejs.org/download/v8-canary/v27.0.0-v8-canary20260521da8e25c394/ now exists with AIX and Linux builds. As @targos mentioned, the other missing platforms will need a newer version of Rust.
StefanStojanovic commentedon May 22, 2026
@richardlau yes, it is my fault, and I apologize. One question: in the
datestringdescription, it says Only needed for nightly, and I was using test builds. For future builds of this job (I plan to run some today), what should I do to prevent the issue I caused? Just adddatestring?StefanStojanovic commentedon May 22, 2026
I'll start another build soon. I'll put a
datestringto avoid the issues described here.richardlau commentedon Jun 4, 2026
Yes, setting the datestring would be the simplest way.
richardlau commentedon Sep 18, 2026
Looking at current ci-release v8-canary jobs, the only recent failing platform is Windows.
which looks like a quoting/delimiter issue?
However it also does look like https://nodejs.org/download/v8-canary/ is behind what is on the DO droplet.
v27.0.0-v8-canary20260918239c3aa75c(build is in progress so more platforms will appear as they complete).@nodejs/web-infra I checked and it looks like we do have
v27.0.0-v8-canary20260918239c3aa75cin R2's dist so this looks like another caching issue with https://github.com/nodejs/release-cloudflare-worker/ similar to the nightlies (nodejs/release-cloudflare-worker#1018).richardlau commentedon Sep 18, 2026
Above was from vs2022_clang-x64. Failure on vs202_clang-arm64:
MattIPv4 commentedon Sep 18, 2026
How recent is this? There is caching in place, so I would not expect a new canary to be available instantly?
richardlau commentedon Sep 18, 2026
That's fair, but then all the builds between 20260904 to today are missing on https://nodejs.org/download/v8-canary/ but are present on the DO droplet and R2 dist. i.e.
we didn't have any builds between 4 September and 15 September. The directory cache for the worker was manually refreshed on 7 September.
MattIPv4 commentedon Sep 18, 2026
🤔 https://github.com/nodejs/release-cloudflare-worker/actions/workflows/update-links.yml runs every day and is meant to update the directory cache. @nodejs/web-infra I'm not sure I know enough about how the worker works to know why this cache isn't refreshing? Does the canary directory need to be added to https://github.com/nodejs/release-cloudflare-worker/blob/1bb1f5403a333564dde7d99dcc6cb75a01697a4a/scripts/constants.mjs#L61-L65 perhaps?
targos commentedon Sep 18, 2026
The Windows build should be (at least partially) fixed by nodejs/node@8273447
We can either wait for V8 15.2 to land on
mainor cherry-pick that fix tocanary-base(I don't have the permission for that)