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

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:


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,

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.


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: