allow_failure 控制作业失败后是否阻断后续阶段，仅影响失败传播行为，不改变执行、触发逻辑或指标采集；推荐在格式审计类 job（如 eslint）中设为 true，并配合 stage 隔离、rules 限定和 retry 提升健壮性。
在 GitLab CI/CD 中，allow_failure 是控制作业失败容忍度的关键开关。它不改变作业是否执行，而是决定“该作业失败后，是否继续运行后续阶段”。对代码格式审计类任务（如 prettier、eslint --fix、sonarqube 扫描）启用此设置，能避免因风格问题阻断构建或部署流程，保障主线交付链路畅通。
明确 allow_failure 的作用边界
它只影响当前 job 的失败传播行为，不影响：
- job 是否运行（仍会照常执行并输出结果）
- 其他 job 的触发逻辑（同 stage 内其他 job 仍并行运行）
- 流水线整体状态显示（UI 上该 job 仍标为 failed，但 pipeline 可标记为 passed）
- 日志和覆盖率等指标采集（只要 job 运行完成，coverage、artifacts 等仍可提取）
在格式审计 job 中正确配置 allow_failure
以 ESLint 静态检查为例，推荐写法如下：
lint:
stage: test
script:
- npm ci --silent
- npx eslint . --ext .js,.vue --quiet
allow_failure: true
only:
- main
- merge_requests
关键点说明：
-
allow_failure: true必须顶格写在 job 定义下，与script、stage同级 - 不要写成
allow_failure: yes或allow_failure: 1—— GitLab 仅识别布尔值true/false - 建议搭配
only或rules限定触发场景，避免在 PR 中误跳过严重错误
配合 workflow 和 stages 实现分层容错
单纯设 allow_failure 不够，需结合阶段设计隔离风险：
- 把格式审计放在
test阶段，而非build或deploy阶段 —— 确保构建和部署逻辑不受干扰 - 用
workflow:rules控制是否运行整条链路，例如：workflow:<br> rules:<br> - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'<br> variables: { SKIP_FORMAT_CHECK: "1" }<br> - when: always
再在 lint job 中加except: $SKIP_FORMAT_CHECK == "1"，实现 MR 场景动态跳过 - 对真正不可降级的检查（如单元测试失败），保持
allow_failure: false（默认值），维持质量底线
注意与 retry、coverage 等关键词的协同
若格式检查本身不稳定（如网络拉取规则超时），可叠加 retry 提升健壮性：
lint: # ... 其他配置 allow_failure: true retry: 2 coverage: '/All files[^|]*\s+[^|]*\s+([^|]*)/'
这样即使某次 ESLint 因临时故障失败，也会重试两次；若最终仍失败，也只影响自身 job，不中断 pipeline。同时保留 coverage 提取，方便在 UI 查看实际覆盖波动。
