选 argo workflows，因其原生支持 kubernetes、调度精细、yaml 清晰，且对 python 项目更适配；jenkins x 则适合已使用且无瓶颈的场景。
Python 项目该用 Jenkins X 还是 Argo Workflows？
选 Argo Workflows，除非你已经在用 Jenkins X 且没遇到明显瓶颈。Jenkins X 是个“带壳的 Jenkins”，对 Python 项目没有特殊优化；Argo Workflows 原生基于 Kubernetes，调度粒度细、状态可追踪、YAML 定义干净，更适合现代 Python 工程的 CI/CD 需求。
Argo Workflows 怎么跑 Python 脚本不卡死？
常见现象是 python script.py 执行完容器直接退出，日志没刷全，或者 pip install 报错说找不到 requirements.txt——根本原因是容器启动后没挂载代码、没设好工作目录、也没等 Python 进程自然结束。
- 必须用
volumeMounts挂载代码（比如从gitRepo或emptyDir），不能靠cp或git clone在容器里临时拉 -
workingDir必须显式设成挂载路径，否则pip install -r requirements.txt会报错No such file or directory - Python 主进程别后台化：避免
nohup python main.py &，Argo 会认为任务已结束，后续步骤拿不到 exit code - 建议用
python -u启动（如python -u train.py），防止 stdout 缓冲导致日志延迟或丢失
Jenkins X 的 jx step syntax 和 Argo 的 workflow YAML 差在哪？
本质区别不是语法，而是抽象层级：jx step syntax 是 Jenkins X 自己封装的一层 DSL，绑定 GitOps 流程（比如自动推 dev 分支、升 staging 环境），但所有操作最终都编译成 Jenkins Pipeline Script；Argo 的 workflow YAML 是直接面向 Kubernetes API 的声明式定义，每个 container 就是一个 Pod，参数、依赖、重试、超时全由字段控制，不绕路。
- Jenkins X 的
jx create spring或jx import会生成大量模板文件（jenkins-x.yml、charts/、env/），Python 项目用不上其中 70% 的 Java/K8s 部署逻辑 - Argo 的
parameters支持运行时传参（如--model-version v2.1），Jenkins X 的preview环境变量只能靠 Git 标签或 PR 注释解析，不稳定 - Argo 的
retryStrategy可按错误码重试（如网络超时重试，ImportError不重试），Jenkins X 的retry是整段 pipeline 重跑，浪费资源
Python 单元测试在 Argo 里怎么才算“真正通过”？
很多团队只看 pytest 是否返回 0，但漏掉两个关键点：覆盖率没达标、警告当错误没拦截。Argo 默认只认 exit code，不会解析 pytest 输出里的 FAILED 或 WARNING 行。
立即学习“Python免费学习笔记（深入）”；
- 加
--strict-markers --strict-config，让未注册的@pytest.mark.xxx直接报错，避免标记失效 - 用
--cov-fail-under=80强制覆盖率低于 80% 时pytest返回非 0，Argo 才会标为失败 - 加
-W error（即python -W error -m pytest），把 DeprecationWarning 当异常抛出，不然 CI 里一堆警告被忽略 - 别用
echo "test passed"收尾——Argo 不解析 stdout，只看进程退出码
Argo 的优势不在“多酷”，而在“每一步都可审计、可中断、可复现”。Python 项目越早把测试、打包、部署拆成独立 container 步骤，后面调试环境差异、依赖冲突、超时策略就越省事。别为了“统一工具链”硬套 Jenkins X，尤其当你连 kubectl 都很少敲的时候，Argo 的 YAML 其实比 Jenkinsfile 更贴近真实执行逻辑。
