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
@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 
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.
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 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.
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 
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 
#prettyplease
