GitLab CI的allow_failure:exit_codes在PowerShell下行为不符合预期

这不是配置遗漏，是GitLab Runner PowerShell执行器的已知行为差异，属于退出码捕获逻辑和Bash环境不一致导致的匹配失效。

Bash环境下，GitLab Runner会直接捕获脚本最后一条命令的原生退出码，和allow_failure.exit_codes列表做匹配；但在16.0之前版本的PowerShell执行器中，Runner会对用户脚本做一层包装执行，直接写裸exit <code>时，PowerShell的原生错误处理流可能会将自定义非零退出码强制转换为1返回给Runner，Runner拿到的实际退出码和脚本里定义的退出码不一致，自然无法匹配放行规则，最终判定作业失败。
allow_failure: true的逻辑是只要作业返回非零退出码就直接标记为警告，不校验具体退出码值，所以不受这个捕获逻辑差异的影响，在PowerShell环境下可以正常工作。

• 升级GitLab Runner至16.0及以上稳定版本
  该版本后官方修复了PowerShell执行器的退出码捕获逻辑，升级后不需要修改现有作业配置，allow_failure.exit_codes就可以和Bash环境下行为一致，按预期匹配指定退出码放行。
• 旧版本Runner兼容写法
  不使用裸exit语句返回自定义退出码，通过显式调用系统API保证退出码能被Runner准确捕获，示例配置如下：

  build:
    script:
      # 执行业务逻辑
      - $host.SetShouldExit(4)
      - exit 4
    allow_failure:
      exit_codes:
        - 4
  

  如果是调用外部exe返回退出码的场景，注意在业务命令执行后不要插入其他PowerShell语句（比如打印日志、变量赋值），避免$LASTEXITCODE被覆盖导致捕获值不准。也可以通过cmd /c "exit 4"的子进程方式返回指定退出码，兼容性更强。
• 无细分退出码需求的临时方案
  如果不需要针对特定退出码做差异化放行，只需要作业失败不阻塞流水线，直接使用allow_failure: true即可，该配置在所有版本的PowerShell执行器下都能正常生效。

修改后可以在作业运行日志中查看Runner记录的实际退出码，只要该值和exit_codes列表中的值匹配，作业就会被标记为带警告通过，不会判定为失败。

内容的提问来源于stack exchange，提问作者Mathieu Westphal