GitHub Actions构建作业无明显原因被取消故障排查

首先排除GitHub Actions时长限制触发的故障：

• 私有仓库GitHub Actions单任务默认超时时长为6小时，你遇到的故障在任务启动3分钟左右触发，远达不到阈值
• 时长限制触发的任务取消，日志末尾会明确打印超时专属报错，不会出现cmd环境特有的Terminate batch job (Y/N)?提示
• 确认是否为时长限制的方法很简单：直接查看失败任务的总运行时长，以及日志末尾的报错关键词即可，不需要额外排查。

这个报错是Windows批处理脚本的典型非交互环境适配问题：
当.cmd/.bat脚本运行过程中出现命令执行错误、收到中断信号时，cmd默认会弹出终止确认提示，等待用户输入Y/N选择是否终止任务。但GitHub Actions的运行器是无交互环境，没有人工输入响应，进程卡在等待输入的状态达到3分钟（运行器对无输出进程的默认超时阈值）后，就会被系统强制取消，打印你看到的报错。
你当前的工作流存在几个未注意到的配置问题：

• 调用build.cmd时没有关闭cmd的交互确认逻辑，遇到异常就会卡住等待输入
• 配置中定义的Solution_Name、Test_Project_Path两个环境变量没有在任何步骤中被引用，属于无效配置
• 缺少.NET SDK版本固定步骤，windows-latest运行器预装的.NET版本可能和你项目要求的版本不匹配，版本兼容问题也可能导致构建过程异常中断，触发交互提示。

按以下顺序调整工作流配置即可解决问题：

1. 在代码拉取步骤后增加.NET环境配置步骤，固定项目使用的SDK版本，避免版本不匹配问题：

- name: 配置.NET环境
  uses: actions/setup-dotnet@v3
  with:
    dotnet-version: 6.0 # 替换为你项目实际使用的.NET SDK版本号

2. 修改构建步骤的执行命令，禁用cmd的交互等待逻辑：

- name: 执行构建
  run: cmd /c build.cmd --target pack --configuration ${{ matrix.configuration }} < nul
  shell: cmd

命令末尾的< nul会给cmd传入空输入流，遇到需要Y/N确认的场景会自动跳过等待，不会卡住。
3. 清理无效配置：如果当前流程不需要执行还原、测试等额外步骤，可以先删掉没被引用的两个环境变量，后续扩展流程时再补充对应配置即可。

如果调整后仍然偶发同类报错，可以在执行build.cmd前增加set CMDCMDLINE=/c配置，彻底关闭cmd的交互提示默认行为。

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