GitLab CI未请求却自动调用PowerShell引发Windows容器CI作业失败

1. GitLab docker-windows执行器的固有运行逻辑
   所有采用docker-windows执行器的GitLab Runner，从设计层面就将Windows PowerShell作为唯一的内置脚本执行引擎，不存在随机无理由触发PowerShell调用的情况：
   • 执行器会自动将before_script、各任务中定义的script字段内容，统一打包为PowerShell格式的临时脚本
   • 固定通过powershell -NoProfile -NoLogo -InputFormat text -OutputFormat text -NonInteractive -ExecutionPolicy Bypass -Command -命令在容器内启动PowerShell进程执行脚本
   • 该流程是硬编码在执行器核心逻辑中的前置步骤，没有开放配置项可以完全绕过PowerShell启动环节。
2. 实际运行镜像不满足执行器依赖
   项目级.gitlab-ci.yml中定义的全局image: microsoft/dotnet:latest配置，优先级高于Runner注册时设置的默认PowerShell镜像，因此运行时实际使用的是dotnet镜像，而非注册Runner时配置的PowerShell镜像。
   拉取到的microsoft/dotnet:latest是基于Nano Server构建的精简镜像：这类为压缩体积裁剪的系统镜像，从Windows Server 2019版本开始默认不内置传统Windows PowerShell组件。当执行器尝试在容器内查找powershell.exe启动进程时，就会直接抛出0x2“系统找不到指定文件”的错误，自定义构建命令完全没有执行机会。

• 更换符合PowerShell依赖要求的.NET SDK镜像
  避免使用无系统版本后缀的latest标签镜像，这类标签通常指向不内置PowerShell的Nano Server精简版本。应直接指定基于Windows Server Core构建的.NET SDK镜像，这类镜像自带完整的Windows PowerShell，完全匹配执行器运行要求。例如可将全局镜像配置调整为image: mcr.microsoft.com/dotnet/sdk:8.0-windowsservercore-ltsc2022。
• 匹配Runner版本的Shell要求
  当前使用的13.11.0版本GitLab Runner，仅支持调用传统Windows PowerShell 5.1，不识别PowerShell 7（pwsh）。即使手动在精简镜像中安装PowerShell 7，只要没有保留传统powershell.exe可执行文件，依然会触发相同的文件找不到错误。若需使用PowerShell 7，需将Runner版本升级到14.0以上，并在Runner配置中显式指定shell = "pwsh"。
• （低优先级）自定义精简镜像
  若对镜像拉取速度有极致要求，可基于现有精简版dotnet镜像，手动打包PowerShell相关运行组件构建自定义镜像。但该方式需要持续维护镜像兼容性，整体维护成本远高于直接使用官方Server Core版SDK镜像。

当前.gitlab-ci.yml中定义在全局的dotnet restore逻辑，会在build、test两个阶段重复执行，可将依赖恢复逻辑合并到build阶段的脚本中，减少重复拉取依赖的耗时。

内容的提问来源于stack exchange，提问作者Hynek Bernard