Open jxy-s opened 1 month ago
The workflow is using an older version, bazel-contrib/setup-bazel@0.8.2
- forgive me if this is already fixed. I can retest with the latest version in a bit.
Confirmed running with latest version shows the same issue: https://github.com/archonitelabs/radiant-cpp/actions/runs/9371722658/job/25801604485?pr=18
For posterity, the extra slash here is necessary: bazel test --test_output=all ///...
- the non-ARM64 one works fine, and this is necessary to work around an idiosyncrasy with PowerShell on windows:
Here is a run with debugging enabled: https://github.com/archonitelabs/radiant-cpp/actions/runs/9371722658/job/25801888908
@jxy-s Your test fails with Error: bash: command not found
- it doesn't seem to be related to setup-bazel.
🤔 I see, I guess I easily overlooked that since the other non-ARM windows machine worked with it. Let me try an alternative.
Okay so using cmd
instead of bash
shows: https://github.com/archonitelabs/radiant-cpp/actions/runs/9372646381/job/25804580277?pr=18
Run bazel test --test_output=all //...
'bazel' is not recognized as an internal or external command,
operable program or batch file.
Error: Process completed with exit code 1.
That's because there is no Bazel installed on GitHub runner, even though it's pre-installed on Windows X64. If you want for the action to install one for you, you need to pass bazelisk-version: 1x
input.
https://github.com/archonitelabs/radiant-cpp/actions/runs/9372804523/job/25805096299?pr=18
Error: Error: Unable to find Bazelisk version 1.x for platform windows/arm64
at downloadBazelisk (C:\a\_actions\bazel-contrib\setup-bazel\0.8.5\dist\index.js:90:1)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at setupBazelisk (C:\a\_actions\bazel-contrib\setup-bazel\0.8.5\dist\index.js:43:1)
at setupBazel (C:\a\_actions\bazel-contrib\setup-bazel\0.8.5\dist\index.js:26:1)
at run (C:\a\_actions\bazel-contrib\setup-bazel\0.8.5\dist\index.js:12:1)
I tried also with 1.20.0
instead of 1.x
.
https://github.com/archonitelabs/radiant-cpp/actions/runs/9372780009/job/25805012776
Error: Error: Unable to find Bazelisk version 1.20.0 for platform windows/arm64
at downloadBazelisk (C:\a\_actions\bazel-contrib\setup-bazel\0.8.5\dist\index.js:90:1)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at setupBazelisk (C:\a\_actions\bazel-contrib\setup-bazel\0.8.5\dist\index.js:43:1)
at setupBazel (C:\a\_actions\bazel-contrib\setup-bazel\0.8.5\dist\index.js:26:1)
at run (C:\a\_actions\bazel-contrib\setup-bazel\0.8.5\dist\index.js:12:1)
@p0deje could this be related to?: https://github.com/bazelbuild/bazelisk/issues/572
Yes, it's related to this issue. If Bazelisk ships a native ARM64 binary, it would work out-of-the-box with setup-bazel. We could work it around for now by forcing x64 architecture on Windows.
The drawback of forcing x64 bazelisk on Windows is that bazel won't use the right toolchain and will compile non-native x64 on ARM64, which is not desired. I think the best course of action is to resolve it in the bazelisk repo and produce an ARM64 binary for Windows.
The drawback of forcing x64 bazelisk on Windows is that bazel won't use the right toolchain and will compile non-native x64 on ARM64, which is not desired. I think the best course of action is to resolve it in the bazelisk repo and produce an ARM64 binary for Windows.
Actually Bazel would still download proper toolchains and compilation should work correctly. I agree that it should be fixed upstream, but in the mean time - can you test p0deje/fix-windows-arm64
branch and let me know if it helps?
I am testing, but I'm confident that this is not going to do what is desired. Windows ARM64 using non-native bazel will build an x64 binary. In the case of a testing workflow that is very much undesired. You want to build and run tests on a native platform. I'll collect data and report back.
I suggest not merging https://github.com/bazel-contrib/setup-bazel/pull/28 until we've come to a consensus here.
For reference: https://github.com/bazelbuild/bazel/issues/22164#issuecomment-2081383179 and https://github.com/bazelbuild/bazelisk/issues/572
It seems like it's still broken for another reason? Looks like bazelisk-version: 1.x
here is succeeding but the command can't locate the newly installed bazelisk
? I tried specifying both bazel
and bazelisk
without luck.
https://github.com/archonitelabs/radiant-cpp/actions/runs/9451455948/job/26032443902#step:4:5
https://github.com/archonitelabs/radiant-cpp/actions/runs/9451414740/job/26032294653?pr=19#step:4:5
Yes, I think there is an issue with how file is added to the tool cache, let me try to prepare another version.
@jxy-s Can you please re-run with debug logs enabled and share here?
Here is a run with debug logs enabled: https://github.com/archonitelabs/radiant-cpp/actions/runs/9452727386/job/26037982135
Maybe that's because .exe is missing from filename, can you try a latest commit?
https://github.com/archonitelabs/radiant-cpp/actions/runs/9454749231/job/26043007626?pr=21
Looks like that fixes the missing bazel
(aka bazelisk
) - however there is already a problem emerging with bazelisk
😄:
Run bazel test --test_output=all -s --toolchain_resolution_debug=.* //...
bazel test --test_output=all -s --toolchain_resolution_debug=.* //...
shell: C:\Windows\system3[2](https://github.com/archonitelabs/radiant-cpp/actions/runs/9454749231/job/26043007626?pr=21#step:4:2)\cmd.EXE /D /E:ON /V:OFF /S /C "CALL "{0}""
2024/06/10 20:01:20 Downloading https://releases.bazel.build/7.1.1/release/bazel-7.1.1-windows-x86_64.exe...
Error: Process completed with exit code -1073741515.
0xC0000135 STATUS_DLL_NOT_FOUND
{Unable To Locate Component} This application has failed to start because %hs was not found. Reinstalling the application might fix this problem.
Looking past that for a moment, bazelisk
is not downloading the correct bazel
. It is installing bazel-7.1.1-windows-x86_64.exe
. That is going to do the wrong thing for an ARM64 Windows machine, explained here: https://github.com/bazelbuild/bazel/issues/22164#issuecomment-2081383179
Anyway, all that aside. I think there are two things here.
bazelisk
needs to provide a native ARM64 binary for Windowssetup-bazel
might need to make a request to update tools for Windows ARM64 support: https://github.com/actions/runner-imagesarchonite-windows-arm64
instead.I actually don't follow how you used Windows ARM64 runner - I don't think GHA provides such a runner and you use something called archonite-windows-arm64 instead.
It is still a GitHub-hosted runner, it's just set up through the Archonite organization. The "Standard GitHub-hosted runners" does not yet include the ARM64 Windows or Linux machines in their set, but you can add them manually.
Link for information on this (and how to set them up) is in the original message in this thread: https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/
It is still a GitHub-hosted runner, it's just set up through the Archonite organization. The "Standard GitHub-hosted runners" does not yet include the ARM64 Windows or Linux machines in their set, but you can add them manually.
I see. This doesn't seem to be available to open-source projects yet, so you'd need to file the issue yourself.
You need to be looking at the organization level, I think you're looking at the project/repo level.
Configured here: https://github.com/bazel-contrib Not here: https://github.com/bazel-contrib/setup-bazel
Anyway, it is available to open-source projects. Radiant is open source under the Archonite organization: https://github.com/archonitelabs https://github.com/archonitelabs/radiant-cpp
The organization itself must be on Team / Enterprise plan, then it's available to its repositories:
Yeah, that tracks with the documentation. Soon enough they'll be available in the standard set for everyone.
Hopefully we can get a bit ahead of the curve here before more people run into issues.
According to the following job it appears that setup-bazel is not functioning when using Windows ARM64 GitHub runners: https://github.com/archonitelabs/radiant-cpp/actions/runs/9359175843/job/25800924517
See also: https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/