Hi @Todiq,
Thanks for reporting this!
We’ll check if we can adjust the command to work with both PowerShell versions or, if needed, expand the config to allow version selection.
Marking this to be reviewed in the next release. We'll keep you updated.

Thanks @Todiq -

windows container with powershell that links to pwsh

Is this common practice? The Microsoft documentation: https://learn.microsoft.com/en-us/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.4 and other references I can find on the matter, do mention that powershell.exe is intentionally different to pwsh.exe precisely to guarantee that powershell.exe (the one that Conan is invoking) is Windows Powershell 5.1.

Just checking if there is more insights as to to why powershell.exe would link to pwsh.exe given that they are in fact incompatible and have a different CLI

https://learn.microsoft.com/en-us/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.4#powershell-executable-changes

What is the rationale behind it?

I believe that's how it is documented to be able to invoke a script in a quote-surrounded file path, which might otherwise result in the string being printed.

Possibly we can pass -Command to be compatible with both - however I'm also not entirely sure any logic inside has ever been tested to work in any newer version of powershell.

Hello @jcar87, @czoido

Thanks for your answers. It is in fact not a common practice, you are right. Here is the complete explanation:

My company has limited CPU resources. While we use GitLab cloud, we only have 2 on-premise GitLab runners running many jobs. One is Linux while the other one is Windows. Both are docker-based runners, meaning that they would start each job in its own docker container (linux or windows based).

GitLab runners are defined by a config.toml file.

On our Windows runner, we chose the docker-windows executor.

Many jobs would use the windows server core image in order to execute commands in a Windows environment. This image only contains powershell 5.

Although written otherwise, the shell does also affect the docker-windows executor. That's why we had to select powershell as the default shell (instead of pwsh). Otherwise, GitLab jobs would search for pwsh on Windows images that do not contain it.

On the other hand, for conan builds, using pwsh provides the conveniency to use the same commands in both Linux and Windows and fixes file encondings (pwsh defaults to UTF8) (#16921).

However, now that powershell has been set as a shell instead of pwsh, GitLab would only look for powershell 5 instead of 7.

The only solution that I found was to create a Windows docker image and replace the original powershell.exe by pwsh.exe to be sure that the runner would call it instead of powershell 5. But that trick led to the aforementioned issue.

Hi @Todiq,

We have merged this for 2.11.0 that will be released soon.
This PR extends the tools.env.virtualenv:powershell to be able to specify powershell.exe to use PowerShell 5 or pwsh to use version 7. It's also possible to add arguments doing something like: tools.env.virtualenv:powershell="pwsh -NoProfile".

I'm going to consider this issue closed by that PR but please feel free to reopen if you have any more questions or need any further assistance.

Thank's a lot!