Make regular canary builds with V8 lkgr

[targos]

There are more and more people who would like to try and use Node.js with the most recent V8 version available. ([1], [2])

I propose that we maintain a canary branch, regularly updated, based on master and upgraded to the latest version of V8. I have already created the branch and applied patches on top of it (most of them cherry-picked from V8's fork, thank you @ofrobots et al!).
CI is running here and looks very promising.
From this branch, we should be able to build canary binaries and publish them to https://nodejs.org/download/.
I also created another branch, canary-base, that is currently exactly the same. The idea is that an automated tool would manage the canary branch, while we use canary-base to manually push fixes.

Here is the general workflow that this tool would follow:

1. git remote update
2. git reset --hard nodejs/master
3. Use update-v8 to upgrade to the latest V8 version
4. Cherry-pick commits from canary-base
5. git push --force nodejs canary

I think it would be valuable for everyone to setup all of this:

• Possibility for people who like to live on the edge to get an easy access to the latest features.
• More testers of the latest master / V8.
• Sooner detection of breaking changes from V8 that affect platform that are not tested by them.
• Easy starting point for Node.js collaborators who want to start implementing things ahead of time with new V8 APIs.

/cc @nodejs/build @nodejs/v8 @ljharb

[1] [2]

[mhdawson]

Seems like a reasonable idea to me.

[ofrobots]

Thanks for writing this up / working on this. It would be great to have a canary build of Node.js available so that we can flow node canary feedback to the V8 team before the V8 dev branches solidify into the beta/stable branches.

A question about the work-flow you proposed: how would the cherry-picking from canary-base work? It sounds like this would be an automated process. How would the tool know what commits should be cherry-picked?

[bmeurer]

I like this idea a lot! Looking forward to Node Canary.

[hashseed]

Looking forward to this!

Does it make sense to check in part of update-v8 into V8 itself? For the file list of dependencies it might make sense?

[hashseed]

I wonder whether it makes sense to port the update-v8 script to python. Requiring Node.js to be able to update Node.js feels weird. Especially if we are looking into checking it into V8 to be able to keep it in sync with V8's version: V8 would have a circular dependency on Node.js.

[targos]

@hashseed

I don't speak python. That's why I wrote it in JS in the first place :).

Requiring Node.js to be able to update Node.js feels weird

It doesn't feel so weird to me. We already need Node.js to be able to lint Node.js with ESLint.

Does it make sense to check in part of update-v8 into V8 itself?

I think it would make a lot of sense to have the list of dependencies in V8 (ideally as a JSON). It is currently here: https://github.com/targos/update-v8/blob/master/src/constants.js#L14-L49
I'm not so sure for the rest of the script. It is more coupled to Node than V8 (directory structure, commit messages). I don't know if other V8 users could benefit from it.

[targos]

@ofrobots

How would the tool know what commits should be cherry-picked?

All the commits after the last V8 update. Something like:

git cherry-pick `git log canary-base -1 --format=format:%H --grep "deps: update V8"`...canary-base

[gibfahn]

We should try to get this up and running in the Collab Summit.

with @piccoloaiutante @targos @fhinkel

EDIT: Will update with progress.

Subtasks:

• A nightly job to update the canary node branch to the Last Known Good Revision branch of V8 and then run node-test-commit.
  • node-update-v8-canary will update nodejs/node-v8:canary and then run a node-test-commit equivalent: node-test-commit-node-v8
• A trigger to the release CI to build the canary branch every night.
  • Added H H(0-7) * * * to the node-update-v8-canary job, it runs every night.

[targos]

The nightly test job works fine and allowed to find and fix quickly some issues.
Latest run is almost green (known issue on FreeBSD: nodejs/node-v8#1, #723).

@gibfahn would you like to help me setup the nightly build?

[gibfahn]

@gibfahn would you like to help me setup the nightly build?

So this would be adding a trigger to the release CI job to upload builds every night? I can definitely help with that, but I'll add this to the Build WG agenda tonight to make sure there are no objections.

[targos]

Yes. I'm thinking about a new https://nodejs.org/download/v8-nightly/ similar to https://nodejs.org/download/chakracore-nightly/

[rvagg]

fyi I have this on my plate, still working on it, it's not a trivial task unfortunately because it also involves the Makefile in core. In the meeting we talked about using "v8-canary" since it roughly aligns with the V8 in Chrome Canary. I'm fine with either that or "v8-nightly". Can we get a consensus here on naming?

[gibfahn]

I prefer v8-canary, I think it better conveys that it's V8 canary and Node master/nightly.

[targos]

v8-canary is fine for me

[kfarnung]

+1 on v8-canary. chakracore-nightly tracks a relatively stable version of ChakraCore (just like normal node nightly builds).

[piccoloaiutante]

+1 for v8-canary also for me

[rvagg]

OK folks, here it is https://nodejs.org/download/v8-canary/

I did some pretty heavy refactoring of the Jenkins iojs+release job on ci-release to make this work nicely but in the process I cleaned up a bunch of old cruft and made it easier to trigger.

I haven't automated this yet, I'll need to do some small tweaks to nightly-builder to handle this nicely, that shouldn't take much effort though.

I wanted to get y'all thinking about how the messaging for this might go—using these builds is going to be a huge mess if you're using addons. They may compile but you're not going to get ABI stability, even across v8-canary versions, and it could potentially break every 6 weeks. So perhaps we could think about a blog post that describes what this is, why you might tinker with them and what kind of breakage you should expect and how to deal with that.

[rvagg]

$ node -p process.versions
{ http_parser: '2.7.0',
  node: '9.0.0-v8-canary20170609cd40078f1f',
  v8: '6.1.101',
  uv: '1.12.0',
  zlib: '1.2.11',
  ares: '1.10.1-DEV',
  modules: '58',
  openssl: '1.0.2l',
  icu: '59.1',
  unicode: '9.0',
  cldr: '31.0.1',
  tz: '2017b' }

[rvagg]

To add to what I said above about messaging—you may not want to promote this too much, I can see people getting much more tangled in this than they would in our slower and more controlled master process that leads to nightly builds. Let's have a talk about limiting uninformed user problems first.

[rvagg]

https://twitter.com/mathias/status/873204105161961473

So much for taking it gently

[mathiasbynens]

My apologies, @rvagg — I was unaware of your request to “not promote this too much” when I posted that.

I’d assume those opting in to canary builds know what to expect, analogous to Chrome Canary: you’re giving up stability for a more bleeding-edge feature set.

I agree that a blog post would help clarify the difference between nightly and canary builds. 👍

[rvagg]

Yeah, no biggie, I'll try and find time soon to draft up a post for you all to review

[rvagg]

PRs to support this in the dist tooling we use:

• support v8-canary builds nodejs-dist-indexer#4
• add support for v8-canary builds nodejs-nightly-builder#1
• add v8-canary builds to www setup #757

They're active on the server now and we have working index.tab and index.json files and there's a cron job in to trigger a job for this every day _if_there's a new commit on nodejs/node-v8/canary. One's running now as I'm writing this and will show up eventually soonish.

[targos]

@gibfahn I have a problem with the node-update-v8-canary job on one of the fedora boxes. It fails consistently because "a cherry-pick or revert is already in progress": https://ci.nodejs.org/view/All/job/node-update-v8-canary/78/console
I cannot reproduce this locally and when the job runs on the other box, it works fine. I don't understand how this can happen because we do git reset --hard origin/master before the update and I think that should abort any cherry-pick that is in progress...

[gibfahn]

@targos odd, it looks like something got messed up in the workspace. I cleaned it out and reran, and now I'm getting: https://ci.nodejs.org/view/All/job/node-update-v8-canary/80/console

 > git fetch --tags --progress [email protected]:nodejs/node.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/canary^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/canary^{commit} # timeout=10
 > git rev-parse origin/canary^{commit} # timeout=10
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

Shouldn't it be looking for canary-base in nodejs/node?

[targos]

Shouldn't it be looking for canary-base in nodejs/node?

Indeed. I changed the config. Trying a new run: https://ci.nodejs.org/view/All/job/node-update-v8-canary/82/console

Edit: back to normal. Thank you!

[gibfahn]

Trying a new run:

Looks like that went better.

LMK if it happens again, I had a look on the machine and none of the directories seemed to have a cherry-pick in progress.

If you have the ability to see the Wipe Out Current Workspace button in the Workspace tab of the job, I recommend wiping and rerunning as a first resort if something starts going wrong. Things seem to get corrupted fairly often in Jenkins.

[targos]

The daily update/test and nightly build work well. I think this can be closed. Thanks everyone for the help!

[targos]

Ah! We still haven't posted anything on the blog about this. @rvagg would you still like to do this draft?

[aalexand]

Would it be possible to publish the headers for the canary build? Currently trying to install a module with C/C++ code gives an error like below.

$ npm link ../nodejs-profilers/

> [email protected] install /some/path/nodejs-profilers
> node-gyp rebuild

gyp WARN install got an error, rolling back install
gyp ERR! configure error 
gyp ERR! stack Error: 404 response downloading https://nodejs.org/download/v8-canary/v11.0.0-v8-canary201807140f69779e03/node-v11.0.0-v8-canary201807140f69779e03-headers.tar.gz

[rvagg]

Headers are produced by our macos builders but they aren't able to compile current v8-canary builds, I guess this is because of the new Xcode/clang limitations for the newer versions of V8. Once that gets sorted out they should start showing up again but I couldn't give an ETA on that.

[aalexand]

@rvagg I am running on Linux fwiw.

[rvagg]

Which is why you have a build, but you'll notice the macos ones are missing. Since the headers tarball comes off our macos machines and those machines aren't able to get through a successful compile we're not getting headers.
Headers are not strictly dependent on a successful build so it's possible that we could adjust the build config so we get headers out but that's going to take some tinkering and a bit of risk. Maybe someone on the build team with access could give it a try.

[richardlau]

I can't test this right now, but I think you should be able to work around this by pointing node-gyp at your Node.js installation which should in theory already include the relevant headers.

e.g. export npm_config_nodedir=/path/to/node

[mmarchini]

I usually use npm install --nodedir=$(dirname $(dirname $(which node))) when using a canary build.

[aalexand]

@mmarchini It worked for me - thanks!