search

nodejs / unofficial-builds

Unofficial binaries for Node.js
https://unofficial-builds.nodejs.org
250 stars 53 forks source link

Windows unofficial builds #2

Closed joaocgreis closed 5 years ago

joaocgreis commented 5 years ago

Since ARM64 Windows was recently added as experimental, it would be good to have builds for testing available somewhere. It is not possible to build these releases in the current unofficial-builds server because they must be built in ARM64 Windows systems, and we don't yet have enough machines to dedicate one for this.

I plan to create a job in test CI to just build a release, from which the artifacts can be manually downloaded and uploaded to the unofficial releases server. Let me know if there is any objection to this.

cc @rvagg

refack commented 5 years ago

🚀

rvagg commented 5 years ago

yep, I imagined being able to have some kind of upload hook for alternative builds, it just needs some way of integrating with the promotion process, perhaps similar to how we do staging->dist promotion with cron for non-release builds on nodejs.org. If you want to do it manually for now then that'd be fine too.

joaocgreis commented 5 years ago

First release done, from https://ci.nodejs.org/view/All/job/build-release-windows-arm64/1/ to https://unofficial-builds.nodejs.org/download/release/v12.1.0/. I'll do this manually for now, there are still a lot of moving parts in ARM64 Windows support. If we don't get it to Tier 2 support soon, I'll look into automating the process somehow.

rvagg commented 5 years ago

I had further thoughts about automation for builds that can't be done on a Linux x64 host: a staging login for each different build type, mirroring the system we use on nodejs.org but isolating each build host to a separate unprivileged login that can only place files onto the server. Then an automatic promotion process can fetch the files, with predictable (fixed) names from a specific place and put them into the download directory along with updated shasums and index.{json,tab}. e.g. a win-arm64 user on the server places files with the pattern: node-{versionstring}-win-arm64.* into ~win-arm64/staging/{versionstring}/ and those files get promoted into ~nodejs/download/release/{versionstring}/. We then have to rely on Linux privileging to lock that down as much as possible and we establish the chain of custody for those files only. If one release build machine becomes compromised, or untrusted for some reason, then we should have some level of confidence that damage is limited.