Re-add Windows arm64 (un)official builds

[dennisameling]

While trying to add Windows arm64 support to GitHub Desktop, I came across some issues with the NodeJS Windows arm64 binaries. The Electron part of the app works fine, as they've been supporting Windows arm64 for a while (e.g. http://electronjs.org/headers/v9.3.1/win-arm64/node.lib).

The last NodeJS release that had unofficial arm64 builds was 12.15.0: https://unofficial-builds.nodejs.org/download/release/v12.15.0/win-arm64/, all versions after that don't have a win-arm64 folder anymore.

gyp http 404 https://nodejs.org/download/release/v12.18.4/win-arm64/node.lib

Even in the latest 14.13.0: no trace of Windows arm64. (https://unofficial-builds.nodejs.org/download/release/v14.13.0/ and https://nodejs.org/download/release/v14.13.0/). Cross-compilation support for Windows arm64 was restored in nodejs/node#32867, but since then no new builds have been released.

error D:\repos\desktop\node_modules\keytar: Command failed.
Exit code: 1
Command: prebuild-install || node-gyp rebuild
Arguments:
Directory: D:\repos\desktop\node_modules\keytar
Output:
prebuild-install WARN install No prebuilt binaries found (target=12.18.4 runtime=node arch=arm64 libc= platform=win32)

D:\repos\desktop\node_modules\keytar>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\bin\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node ""C:\Users\Dennis\AppData\Roaming\npm\node_modules\node-gyp\bin\node-gyp.js"" rebuild )
gyp info it worked if it ends with ok
gyp info using node-gyp@6.1.0
gyp info using node@12.18.4 | win32 | x64
gyp info find Python using Python version 3.7.3 found at "C:\Program Files\Python37\python.exe"
gyp http GET https://nodejs.org/download/release/v12.18.4/node-v12.18.4-headers.tar.gz
gyp http 200 https://nodejs.org/download/release/v12.18.4/node-v12.18.4-headers.tar.gz
gyp http GET https://nodejs.org/download/release/v12.18.4/SHASUMS256.txt
gyp http GET https://nodejs.org/download/release/v12.18.4/win-x86/node.lib
gyp http GET https://nodejs.org/download/release/v12.18.4/win-x64/node.lib
gyp http GET https://nodejs.org/download/release/v12.18.4/win-arm64/node.lib
gyp http 200 https://nodejs.org/download/release/v12.18.4/SHASUMS256.txt
gyp http 404 https://nodejs.org/download/release/v12.18.4/win-arm64/node.lib
gyp http 200 https://nodejs.org/download/release/v12.18.4/win-x86/node.lib
gyp http 200 https://nodejs.org/download/release/v12.18.4/win-x64/node.lib
gyp info find VS using VS2019 (16.7.30503.244) found at:
gyp info find VS "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community"
gyp info find VS run with --verbose for detailed information
gyp info spawn C:\Program Files\Python37\python.exe
gyp info spawn args [
gyp info spawn args   'C:\\Users\\Dennis\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\gyp\\gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'msvs',
gyp info spawn args   '-I',
gyp info spawn args   'D:\\repos\\desktop\\node_modules\\keytar\\build\\config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'C:\\Users\\Dennis\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   'C:\\Users\\Dennis\\AppData\\Local\\node-gyp\\Cache\\12.18.4\\include\\node\\common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=C:\\Users\\Dennis\\AppData\\Local\\node-gyp\\Cache\\12.18.4',
gyp info spawn args   '-Dnode_gyp_dir=C:\\Users\\Dennis\\AppData\\Roaming\\npm\\node_modules\\node-gyp',
gyp info spawn args   '-Dnode_lib_file=C:\\\\Users\\\\Dennis\\\\AppData\\\\Local\\\\node-gyp\\\\Cache\\\\12.18.4\\\\<(target_arch)\\\\node.lib',
gyp info spawn args   '-Dmodule_root_dir=D:\\repos\\desktop\\node_modules\\keytar',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'D:\\repos\\desktop\\node_modules\\keytar\\build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info spawn C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe
gyp info spawn args [
gyp info spawn args   'build/binding.sln',
gyp info spawn args   '/clp:Verbosity=minimal',
gyp info spawn args   '/nologo',
gyp info spawn args   '/p:Configuration=Release;Platform=ARM64'
gyp info spawn args ]
Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
  async.cc
  main.cc
  keytar_win.cc
  win_delay_load_hook.cc
LINK : fatal error LNK1181: cannot open input file 'C:\\Users\\Dennis\\AppData\\Local\\node-gyp\\Cache\\12.18.4\\arm64\\node.lib' [D:\repos\desktop\node_modules\keytar\build\keytar.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Users\Dennis\AppData\Roaming\npm\node_modules\node-gyp\lib\build.js:194:23)
gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR! System Windows_NT 10.0.19041
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Dennis\\AppData\\Roaming\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd D:\repos\desktop\node_modules\keytar

Are there any blockers to start releasing Windows arm64 builds for NodeJS? AFAIK we should be good to go:

• jenkins: add ARM64 Windows #2408 is merged (add arm64 to Jenkins)
• build: move compiling for Windows ARM64 to Tier 2 node#34721 is merged (move Windows arm64 to Tier 2 support)

According to nodejs/node#25998 (comment):

The next step is to update the job used for unofficial releases and start publishing them again. Note that for now there will be no MSI because WiX 3.14 is not yet released, but as soon as it is we should get the MSI as well.

Please let me know if I can be of any help. Very eager to help open source projects get arm64 support to the Windows platform soon 😊

[AshCripps]

Best person to ask would be @joaocgreis as I believe the machines used to build it are hosted on his desk.

[joaocgreis]

v14.13.0 published: https://unofficial-builds.nodejs.org/download/release/v14.13.0/

It was not possible to run the tests for this release because the machines we have are currently offline, I'll check on them and run the tests when possible. @dennisameling if you can try the release and confirm it works, that would be appreciated.

Note the release process for this is manual - the unofficial releases server uses docker for the Unix platforms but for Windows it must run in the CI test machines. I will try to publish releases frequently but can't commit to publish every version.

To move this further forward, we need ARM64 machines to become available in Azure.

[dennisameling]

Thanks @joaocgreis! Can confirm the release works. Have been trying some things and all looks good so far.

I was also able to build an MSI installer from the v14.13.0 tag, here's the link in case someone's interested: https://github.com/dennisameling/node/releases/tag/v14.13.0-arm64 (I'm using this on my Surface Pro X now 🎉)

Have you considered running a self-hosted Azure Pipelines agent, like the Electron team is doing? You can run the 32-bit Azure Pipelines agent on an ARM64 device like the Surface Pro X.

Hopefully that's a feasible workaround for the time being; I'll try to get in touch with Azure support to ask when ARM64 machines will become available. Guess it's only a matter of time, hopefully sooner than later 🚀

UPDATE: Got a response from Azure Support on Twitter. They don't have info regarding potential availability of ARM64 runners at the moment: https://twitter.com/AzureSupport/status/1313067495444688896. Have created a support case with the Azure DevOps team just to cross-check with them as well.

UPDATE 2: Got a response from Azure Support in my ticket:

In regards to the reported scenario I would like to let you know that I have checked the Azure DevOps Roadmap, the Azure DevOps Features Timeline and also discussed the ticket internally with the escalation engineers and unfortunately the desired feature / functionality is not available.

What we can recommend in this situation is to go to the developer community and request this as a new feature for DevOps: https://developercommunity.visualstudio.com/content/idea/post.html?space=21 .
We use this tool to learn what our customers want and where we should focus on improving. People can make their own suggestions and vote on others’ suggestions they’d like to see. Our product group then tries to implement the suggestions that have a lot of community support.

I created a feature request back in May, please upvote if you'd like to see hosted Windows ARM64 agents in Azure: https://developercommunity.visualstudio.com/idea/1015752/please-add-a-windows-arm64-hosted-agent.html

For the time being, a self-hosted Azure Pipelines Agent on e.g. a Surface Pro X could be an option maybe, as mentioned above.

[joaocgreis]

Published v14.13.1.

CI: https://ci.nodejs.org/view/All/job/node-test-commit-windows-fanned/38639/

test-dgram-udp6-link-local-address seems to always fail, but it may be because of the configuration of the machine.

@dennisameling we are using essentially the same thing as a self-hosted agent, but connected to our Jenkins system. This is not a reliable setup though, the machine was offline and I could only bring it back now. That's one of the reasons why we need the cloud hosted machines, the other is simply we need more machines.

[joaocgreis]

Published v15.5.1.

[EwoutH]

Could the win-arm64 directory, including node.lib, be retroactively be added to the latest LTS versions? So at least v12.20.1 and v14.15.4.

[joaocgreis]

Published v14.15.4 and v15.8.0.

@EwoutH didn't publish v12 because it doesn't have ARM64 support.

[joaocgreis]

Published v14.17.0 and v16.2.0.

From the CI runs (14, 16) it looks like there's a new failure running node-gyp. I can't investigate now, it may be only an issue with CI or may be relevant.

[joaocgreis]

Published v14.17.5 and v16.6.2.