在 github actions 中，需同时获取 python 脚本的标准输出（含多行内容）并准确传递其退出码（如 0/1）以控制工作流状态，避免因重定向导致 exit code 丢失。
在 github actions 中，需同时获取 python 脚本的标准输出（含多行内容）并准确传递其退出码（如 0/1）以控制工作流状态，避免因重定向导致 exit code 丢失。
在 CI/CD 自动化中，常需运行校验脚本（如 check_data.py），既要在 Pull Request 下自动评论输出结果，又需根据脚本退出码（0 表示通过，1 表示失败）决定后续步骤是否执行或标记任务失败。但直接使用 echo "$(python script.py)" >> "$GITHUB_OUTPUT" 存在致命缺陷：命令替换 $() 会吞掉原始命令的退出码——无论 Python 脚本返回 0 还是 1，外层 echo 总是成功（exit code 0），导致工作流无法感知真实失败。
✅ 正确方案：用 tee + 临时文件替代命令替换
核心思路是分离“捕获输出”与“传播退出码”两个目标：不再依赖 $() 捕获 stdout，而是让脚本原生执行，并用 tee 实时分流输出到文件和终端，最后通过 $? 显式检查并保留原始退出码。
以下为推荐的稳健实现（适配 PR 和 push 场景）：
- name: Run script
id: check_data
shell: bash
run: |
# 执行脚本，实时输出到终端（便于日志调试）并保存到文件
python tools/check_data.py "$BRANCH" | tee comment.txt
# 关键：显式检查并返回原始退出码
exit_code=$?
if [ $exit_code -ne 0 ]; then
echo "Script failed with exit code $exit_code" >&2
exit $exit_code
fi? 为什么不用 HEREDOC（
GitHub Actions 官方文档明确建议对多行字符串优先使用文件方式（见此）。HEREDOC 在复杂输出（如含 EOF 字符串、特殊转义）下易出错，且需额外配置 set -o pipefail 才能传递管道内命令的退出码，增加维护成本。
✅ 后续步骤：安全读取输出并自动评论
一旦 comment.txt 文件生成，即可在后续步骤中可靠读取（无需担心 $GITHUB_OUTPUT 多行解析问题）：
- name: Auto comment on PR
if: github.event.pull_request
uses: marocchino/sticky-pull-request-comment@v2.9.0
with:
recreate: true
header: data-validation
path: comment.txt
- name: Show summary on push
if: github.event_name == 'push' && (github.head_ref == 'main' || github.head_ref == 'develop')
run: |
echo "## Data Check Results" >> "${GITHUB_STEP_SUMMARY}"
echo "" >> "${GITHUB_STEP_SUMMARY}"
cat comment.txt >> "${GITHUB_STEP_SUMMARY}"⚠️ 关键注意事项
- 禁止省略显式 exit $?：若只写 python ... | tee file.txt，Bash 默认返回管道最后一个命令（tee）的退出码（几乎总是 0），必须手动捕获并重抛。
- 环境变量安全：推荐在 env: 块中声明 BRANCH，而非 echo "BRANCH=..." >> "$GITHUB_ENV"，可规避脚本注入风险（GitHub 安全指南）。
- 超时防护：为关键作业添加 timeout-minutes（如 20），防止挂起脚本阻塞整个工作流。
- 权限最小化：仅在需要评论 PR 时申请 pull-requests: write 权限，避免过度授权。
该方案已在生产级仓库验证（示例 PR），兼顾可靠性、可读性与安全性，是处理“输出+退出码”双重需求的 GitHub Actions 最佳实践。
