Use a self-hosted runner for the Windows build.

[kring]

No description provided.

[weegeekps]

@lilleyse and I think that we need the image to have the visualstudio2022-workload-nativedesktop choco package for the build to pass. We noticed that there are some environment variables around the WinSDK are missing, and suspect that package should fix this.

Also, you may want to add doxygen.install to the image as well. We aren't currently building the docs in CI, but as we get closer to release we are planning on doing so. Finally, could you also add LLVM? Specifically version 14. The command for that is choco install llvm --version=14.0.6 for reference so you don't need to look it up yourself.

[kring]

Ok cool I'll add those. If you want, you can add those Choco commands to the beginning of your build script as a test, to make sure nothing else is missing. And then remove them once the image is updated.

[kring]

Well, the image is updated, but it's still not working. If you look at the beginning of the Configure step, where it lists all the environment variables, you can see that C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.34.31933\bin\HostX64\x64 is the first thing in the PATH. And that directory does indeed have cl.exe in it. So I'm not sure what cmake is complaining about. Perhaps the problem is that cmake has been told to use cl instead of cl.exe? Seems odd, but I'll try it.

[kring]

cl.exe didn't help. The problem seems to be that the PATH and other environment variable updates done by msvc-dev-cmd aren't making it through to the Configure step. I also noticed that on the new self-hosted runner, the beginning of the Configure step prints "Refreshing environment variables from the registry for powershell.exe", but on the Github-hosted runner it does not. The GH runner is also using Powershell 7, whereas our runner uses the default shipped with Windows. So I'm building a new image with Powershell 7 installed to see if it helps.

[kring]

Installing Powershell 7 fixed that problem. On to the next...

Conan seems to be having a problem with long paths. See here:
https://github.com/CesiumGS/cesium-omniverse/actions/runs/4039281888/jobs/6943859506#step:9:202

I confirmed that the image has long paths enabled:

PS C:\Windows\system32> Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\FileSystem' -Name 'LongPathsEnabled'


LongPathsEnabled : 1
PSPath           : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem
PSParentPath     : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control
PSChildName      : FileSystem
PSDrive          : HKLM
PSProvider       : Microsoft.PowerShell.Core\Registry

And I also tested it by creating the file that Conan is complaining about, and it was successful. So there's probably a problem with Conan itself or something it uses that prevents the use of long paths (which is, infuriatingly, a really common problem).

This is showing up because the workspace directory used by Github-hosted runners is much shorter than the one in this self-hosted runner. I couldn't work out how to fix that in the short term I was willing to spend on it, but have added a partial workaround for now by using "d:" as the Conan directory. The actual workspace directory is just a symlink to d:\ anyway in this runner image.

That makes Conan happy, but cmake is still losing its mind. I guess I'll need to fix the workspace directory for real. Perhaps I've somehow failed to actually enable long paths? But I don't see how.

[kring]

Ok this should be in good shape now, after moving the action runner working directory to d:\. Let me know if you run into any problems. You may also want to increase your build parallelism, because the new runners have 8 cores and 16 gigabytes of RAM (They're AWS c6id.2xlarge spot instances).

[lilleyse]

I thought we were safe from long path issues... oh well... the workaround is fine for now.

Thanks @kring for setting this up for us.