ci/cd流水线阻塞主因是required_status_checks的context名与ci实际报告名不一致；enforce_admins:true会阻止管理员绕过检查；git push--force被拒但ci仍触发；pr批准后ci失败仍可合并。
CI/CD 流水线被阻塞在 required_status_checks 上
这是最常见的情况：PR 提交后，GitHub/GitLab 显示 “Some checks haven’t completed yet”，但 CI 任务实际早已跑完，状态却迟迟不更新。根本原因往往是 required_status_checks 中列出的 context 名称与 CI 工作流实际报告的名称不一致。
比如 GitHub Actions 默认把 job 名作为 status context，但你配置的是 "ci/build"，而 workflow 中 job 写的是 build-app，那检查永远通不过。GitLab 的 pipeline trigger 名、Jenkins 的 job ID 格式也常有类似偏差。
- 用
curl -H "Authorization: Bearer $TOKEN" https://api.github.com/repos/{owner}/{repo}/commits/{sha}/status查看真实上报的 contexts 列表 - GitHub Actions 中显式指定 status context：
if: ${{ always() }}<br> name: Report build status<br> uses: actions/github-script@v6<br> with:<br> script: |<br> github.rest.repos.createCommitStatus({<br> owner: context.repo.owner,<br> repo: context.repo.repo,<br> sha: context.sha,<br> state: 'success',<br> context: 'ci/build'<br> }) - GitLab CI 可通过
coverage或after_script主动上报，避免依赖默认 pipeline 名
enforce_admins: true 导致管理员无法绕过 CI 强制合并
很多团队误以为开启 enforce_admins: true 是“更安全”，结果在紧急 hotfix 场景下卡住——即使管理员手动点击 Merge，系统仍要求所有 status checks 通过。这不是 bug，而是设计使然：该字段强制所有人（含 Owner）遵守规则。
真正需要的是分级策略：对 main 严格 enforce，但对 hotfix/* 分支允许 bypass CI（需配合 branch pattern 和权限分组）。
- GitHub 不支持 per-branch 的
enforce_admins开关，只能靠多条规则匹配不同分支模式 - GitLab 支持按分支规则单独设置 “Allow admins to merge when checks fail”，比 GitHub 灵活
- 若必须保留
enforce_admins: true，建议配套配置dismiss_stale_reviews_on_push: true，防止旧 review 阻塞新提交
分支保护启用后，git push --force 失败但 CI 仍触发
开发者执行 git push --force 被拒绝是预期行为，但很多人没意识到：只要 push 成功（哪怕只是普通 push），CI 就会照常触发。如果某次 PR 合并后又强制推送了旧 commit，CI 会基于错误历史运行，导致测试通过但代码实际回退。
这不是分支保护失效，而是保护机制和 CI 触发逻辑天然脱钩——保护只管“能不能推”，不管“推的内容是否合理”。
- GitLab 可启用 “Push Rules” 中的 “Prevent force push” 选项（数值为
0），从服务端拦截 --force - GitHub 没有等效 UI 选项，需用 pre-receive hook 或第三方工具（如 Probot）拦截
- 更稳妥的做法是在 CI 脚本开头加校验：
if git merge-base --is-ancestor HEAD~1 origin/main; then echo "OK"; else exit 1; fi，确保当前 HEAD 是 main 的后代
自动化构建失败时，required_pull_request_reviews 却被跳过
当 PR 的 CI 全部失败，但仍有 reviewer 点击 Approve，GitHub 仍允许合并——因为分支保护只检查“是否有足够 approve”，不校验 approve 发生时 CI 是否已通过。这会导致带缺陷代码直接进主干。
关键点在于：approval 状态是静态快照，而 CI 状态是动态刷新的。两者没有原子绑定。
- GitHub 原生不支持 “approval only valid if CI passes at time of approval”
- 可行解是用 GitHub Action 监听
pull_request_review事件，自动撤回过期 approve（需搭配pull_request事件监听 CI 状态变更） - GitLab 的 “Merge request approvals” 设置里有 “Reset approvals when new commits are pushed”，可部分缓解该问题
