[March, 2022] Beta support for new operating system for Windows Executors: Windows Server 2022

@uhlenbrock yes you can use the windows server 2022 image just like that without using orbs, just use image: windows-server-2022-gui:edge instead.

Thanks for the confirmation, @mrothstein74 — but when I use that setting I get the error referenced above: failed to create host: Image windows-server-2022-gui:edge is not compatible with resource class l1.large

@uhlenbrock can i see your config? I am not having issues on my end when setting resource_class: windows.large or when setting resource_class: windows.medium. I just want to be sure I understand the issue. Thanks!

Hi @mrothstein74 - I tried image: 'windows-server-2022-gui:edge' and it isn’t working with nvm unfortunately.

The main issue is running the nvm use command produces exit status 145: The directory is not empty.

Here’s a powershell log of installing an nvm version and trying to use it:

PS C:\Users\circleci.PACKER-624EE792> node -v
node -v
v17.4.0
PS C:\Users\circleci.PACKER-624EE792> nvm install 14.19.0
nvm install 14.19.0
Downloading node.js version 14.19.0 (64-bit)... 
Complete
Creating C:\ProgramData\nvm\temp

Downloading npm version 6.14.16... Complete
Installing npm v6.14.16...

Installation complete. If you want to use this version, type

nvm use 14.19.0
PS C:\Users\circleci.PACKER-624EE792> nvm use 14.19.0
nvm use 14.19.0
exit status 145: The directory is not empty.

exit status 145: The directory is not empty.

PS C:\Users\circleci.PACKER-624EE792> node -v
node -v
v17.4.0

@laupow hi please try the steps in this forum:

I was able to workaround exit status 145 by running Remove-Item -Recurse -Force "C:\Program Files\nodejs" before nvm commands.

Seems like something could be ironed out in the Windows image? I didn’t have to delete the nodejs folder on Windows 2019. But the issue seems common for nvm-windows: exit status 145: The directory is not empty , when I run command : nvm use 16.10.0 · Issue #674 · coreybutler/nvm-windows · GitHub

Installing tools from NuGet gives the message:
Since you just installed the .NET SDK, you will need to reopen the Command Prompt window before running the tool you installed.
Is this is a bug or is there anyway to “restart” the CLI or a similar workaround?
This makes those tools very hard to use.

@Fischchen can you send me the section of config where you install your tool? The section giving you this message?

@laupow Hi I will take care of this in the next version of the image. Please let me know of any other issues. Thank you!

@mrothstein74
One example is:

      - run:
          name: Install Test converter
          command: dotnet tool install --global trx2junit
          shell: cmd.exe

But this happens when installing every dotnet tool

@laupow please try the new edge image and let me know if there is still an issue. Thank you!

@Fischchen please try the new edge image. Apparently this is a Microsoft issue. After installing a new tool regardless if it is right after installing the SDK you need to open a new windows for it to be available in the path.

Here is a workaround that I use:

Here is an article discussing the issue:

Please let me know if you have further issues

Thanks!
Michael Rothstein

@Fischchen just checking in to see if this solved your problem. Thanks!

There is an issue setting environment variables from Powershell which doesn’t occur in server-2019 but does with the edge/current/stable 2022 images.

To reproduce, use any of these commands in one step, then try access the variable in a subsequent step:

setx "Key1" "Value1"
[Environment]::SetEnvironmentVariable("Key2", "Value2", [System.EnvironmentVariableTarget]::User)

[Environment]::SetEnvironmentVariable("Key3", "Value3", [System.EnvironmentVariableTarget]::Machine)

@mitchell-demol Hello can you try this in a subsequent step after you set your env var and let me know the result?

- run:
          name: get env var
          command: Get-ItemPropertyValue 'registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' MYVAR 
          shell: powershell.exe -ExecutionPolicy Bypass

This is on the image “windows-server-2022-gui:current”

@mitchell-demol we do not currently support setting an env var in a step and have it be available in a subsequent step on any OS. Please refer to this link:

https://discuss.circleci.com/t/passing-variables-to-other-steps/27700

The recommendation would be to write to a file and read the values back in, or read/write to the registry.

I can make a recommendation that this be supported in the future.

Thank you,
Mike

Hi @mitchell-demol !

As Mike mentioned above, I believe there is no supported/built-in feature on our end to “pass” an env var set in prior step when using PowerShell on a Windows executor then.

I was able to confirm this too on this sample build.
(you can inspect the config here.)

However, as you may be aware, we do provide a $BASH_ENV file that is sourced between each step.
See Using Environment Variables - CircleCI

If you are able to switch to using Bash (instead of Powershell), I believe you can take advantage of this, to pass an env var over to the next step.
And yes, you can certainly switch shell from Powershell to Bash, even in Windows :slight_smile:

In fact, I have tested this on the windows-server-2022-gui:current Windows executor too.
You can inspect the config, and the build here.

I know this is about using Bash, not Powershell, so it may not necessarily fit your needs.
However, I hope this gives you an additional option / next step.

@kelvintaywl, @mrothstein74

I do remember reading the environment variables page linked, I believe that because it is based on Bash I decided to just try PowerShell commands (our pipeline uses PS scripts not Bash) and see what works - which my method does for windows 2019. Hence, we have a number of jobs which get/set environment variables for use in subsequent steps as it is simple to access them with $env:VAR.

Thanks for the suggestions, I already had implemented some workarounds and I would rather not use Bash. I thought that this was unintended behaviour, given that it does work in the windows 2019 images and PS should update these if each step is a new shell.

I found that for the 2019 image there is a PS profile which refreshes the environment variables in a new shell:


This isn’t the case for the 2022 image (I also checked elsewhere but couldn’t find it):

So perhaps you could add this to the setup in the 2022 image?

This is also related to the other issue in this thread about trx2junit. In our build, we have cached trx2junit so we must add the installation directory to the path variable after we retrieve from cache. Note: we cache to the default 2019 image circleci user directory, even though this is not the same in the 2022 image.

[Environment]::SetEnvironmentVariable("Path", "$env:Path;C:\Users\circleci\.dotnet\tools", [System.EnvironmentVariableTarget]::User)

We also have other steps which add to path like this. This leads to a similar failure as other people were having, as the PS path variable is not updated even if the registry entry is.


I had resorted to simply using the full path here to fix this problem.

It is not a huge issue to workaround, but it would be good if it was supported.

Thanks

Would it be possible to have wixtoolset installed by default in the windows images? We use it to build MSIs. I can of course install it every time with chocolatey but as you have a ton of nice goodies added by default this could be another :wink:

FWIW, it seems to take around 1 min 30 seconds - 2 minutes 30 seconds to do “choco install -y wixtoolset” on a medium (the default) sized windows execution environment which I think is slightly excessive considering my golang builds are significantly less than that. So most of the image time is actually spent setting up the tooling.

Update: got the install time down to ~20-30 seconds by using nuget (“nuget install WiX -Version 3.11.2”) rather than choco :+1:

#prettyplease