流水线执行规则是什么：触发条件与失败处理机制

2026年11月11日

流水线执行规则是流水线在什么条件下启动、按什么顺序和依赖关系运行、遇到超时或失败如何处置、哪些环节需要人工确认的一组约定。它管的是“这条流水线怎么跑”，与“这次发布能不能放行”分属执行层和放行层。下面按触发条件、串并行与依赖、超时与重试、失败处理、人工确认五类要素逐项说明，并给出一个完整示例。

Table of Contents

要点总览（TL;DR）

流水线执行规则是约束流水线何时启动、按什么顺序运行、超时或失败如何处置、哪些环节需要人工确认的一组约定，管的是运行过程，不管发布是否放行。
触发条件除代码提交和合并请求外，还包括定时调度、手动触发和上游流水线或外部事件；写规则时要同时限定分支与路径范围、触发人权限、并发排队与重复触发的去重或取消策略。
阶段编排依据产物依赖确定串行顺序，并行要求阶段之间不争用共享资源且结果互不依赖；失败是否传导到下游应在规则中显式约定。
失败处理的关键是区分失败类型：环境性失败可自动重试一至两次，编译错误、测试断言失败等确定性失败应直接判定失败并通知责任人，同时保留日志与产物、标记版本状态。
执行规则与发布准入、质量门禁分属执行层与放行层，衔接点是门禁结果作为流水线阶段的通过条件，门禁不通过时按执行规则决定中断、通知还是人工豁免。

流水线执行规则包含哪些控制要素

流水线执行规则是对流水线运行过程的约束性约定，回答五个问题：何时跑、按什么顺序跑、跑多久、跑挂了怎么办、谁来拍板。这五个问题对应五类控制要素，共同构成执行规则的完整框架。

控制要素	回答的问题	典型内容
触发条件	何时跑	代码提交、合并请求、定时调度、手动触发、上游流水线或外部事件
串并行与依赖	按什么顺序跑	阶段划分、串行先后、并行条件、上游产物作为下游输入
超时与重试	跑多久、失败了要不要再试	阶段或整体时限、可重试与不可重试的失败类型
失败处理	跑挂了怎么办	中断后续阶段、保留日志与产物、通知责任人、标记版本状态
人工确认	谁来拍板	进入生产环境前、高风险变更、跨团队交付的确认节点

这五类要素需要一起写清楚，规则才可执行。只写触发条件不写失败处置，流水线跑挂后无人知道该重跑还是该修代码；只写阶段顺序不写超时，一个卡住的阶段会长期占用执行资源。执行规则的价值在于把运行过程中的判断提前约定下来，减少每次运行时的临时决策。

触发条件：流水线在什么情况下启动

触发条件决定流水线在哪些事件发生时自动或手动启动。常见触发方式有四类，适用场景不同。

代码提交或合并请求触发：开发者推送代码或发起合并请求时启动，适合持续集成场景，能尽早发现集成问题。合并请求触发通常只跑与变更相关的检查，提交触发则可能跑更完整的验证。
定时调度触发：按固定时间启动，适合夜间全量回归、依赖更新检查、定期构建等不依赖单次提交的场景。
手动触发：由有权限的人员主动发起，适合发布、回滚、临时验证等需要人为判断时机的操作。
上游流水线或外部事件触发：上游流水线成功后启动下游流水线，或由制品发布、外部系统事件等驱动，适合多流水线串联的交付链路。

触发条件不能只写“有提交就跑”，还需要限定几个字段。分支与路径范围决定哪些变更会触发，例如只对主干和发布分支生效，或只在特定目录变更时触发，避免文档修改也跑全量构建。触发人权限决定谁可以手动启动或跳过某些检查。并发与排队策略决定同一流水线已有实例在跑时，新触发是排队等待、并行执行还是取消旧实例。

同一代码版本重复触发时的去重或取消策略也需要明确。合并请求频繁更新时，如果每次推送都保留一个运行实例，会浪费执行资源并让结果难以判断。常见做法是新提交到达时取消同一合并请求下尚未完成的旧实例，只保留最新一次运行的结果作为判断依据。

串并行与依赖：阶段如何排序和衔接

阶段编排规则决定流水线启动后各环节的先后与衔接方式。典型流水线按构建、测试、制品产出、部署的顺序串行推进，前一个阶段成功才进入下一个阶段。串行顺序的依据是产物依赖：测试需要构建产物，部署需要制品，顺序颠倒则环节无法执行。

并行执行能缩短整体时长，但有前提条件。两个阶段可以并行，通常要求它们不争用同一份共享资源，且结果互不依赖。例如单元测试与静态代码检查可以并行，二者都基于同一份代码，互不消费对方输出；而集成测试依赖构建产物，就必须排在构建之后。环境与资源占用也影响并行度：多个阶段同时部署到同一套测试环境会互相干扰，此时要么串行，要么为并行阶段分配独立环境。

依赖规则还包括跨流水线衔接和失败传导。上游流水线的产物作为下游流水线的输入时，需要约定产物版本如何传递、下游何时启动。失败时下游是否继续，取决于业务判断：上游构建失败，下游测试通常没有继续的意义，应直接终止；上游某个非关键检查失败，下游是否继续可以由规则显式约定，避免每次运行临时决定。

超时、重试与失败处理机制

超时、重试与失败处理是执行规则中处置异常的部分，回答“跑多久”和“跑挂了怎么办”。

超时设置按阶段或整体设定时限。阶段级超时适合耗时差异大的流水线，例如构建限时二十分钟、集成测试限时一小时；整体超时适合对外承诺总时长的场景。超时后流水线应终止该阶段并标记为超时失败，而不是无限等待。超时值需要根据历史运行时长设定，过紧会造成误杀，过松则失去保护意义。

重试规则的关键是区分失败类型。网络抖动、临时资源不足、依赖服务短暂不可用这类环境性失败，自动重试一至两次往往能恢复；编译错误、测试断言失败、配置缺失这类确定性失败，重试只会重复同样的结果，应直接判定失败并交由人处理。重试次数和间隔需要写进规则，避免无限重试掩盖真实问题。

失败处理动作包括：中断后续阶段，防止基于失败产物继续推进；保留日志与产物，供排查使用；通知责任人，通知对象按阶段或失败类型指定；标记版本状态，让该代码版本在后续判断中处于明确的失败状态，不被误当作可发布版本。

失败后的恢复方式需要约定条件。从失败阶段续跑适合失败点之后阶段耗时较长、且前面阶段产物仍然有效的情况；整体重跑适合产物可能已受污染、或流水线状态不确定的情况。规则中写明哪种情况用哪种恢复方式，可以减少恢复时的争议。

人工确认环节在执行规则中的位置

人工确认是执行规则中由人拍板的节点，与自动处置互补。典型需要人工确认的节点包括：进入生产环境前的发布确认、高风险变更（如数据库结构变更、核心配置调整）的执行确认、跨团队交付中接收方的验收确认。这些节点的共同点是后果较重或责任需要明确到人，不适合完全自动放行。

确认人的角色与权限需要写清楚：谁有权确认、是否需要多人确认、确认人能否看到判断所需的构建结果与测试报告。确认超时或无人处理的默认走向也要约定，常见做法是超时后保持暂停并提醒，而不是默认通过；对时效要求高的场景，也可以约定超时后自动取消本次运行。

人工确认通过后，流水线从确认节点继续执行后续阶段，确认动作本身应留下记录，包括确认人、确认时间、确认时的流水线状态。这条记录既是执行过程的一部分，也为后续追溯提供依据。在 ONES 中，需求、任务等工作项可以与代码提交和流水线数据关联，流水线执行状态和日志会同步到项目中，团队可以在工作项上下文里查看构建结果与发布进展，人工确认前后的状态变化也有迹可循。

执行规则与发布准入、质量门禁的边界

执行规则与发布准入、质量门禁是相邻但不同的两层约定。执行规则管运行过程：何时启动、怎么跑、失败怎么办。发布准入与质量门禁管放行判断：指标是否达标、是否允许进入下一环境或对外发布。前者是执行层，后者是放行层。

维度	流水线执行规则	发布准入与质量门禁
管理对象	流水线本身的运行过程	某次发布或某个版本能否放行
核心问题	何时跑、按什么顺序跑、失败怎么办	指标是否达标、是否允许进入下一环境
典型内容	触发条件、串并行、超时重试、失败处置、人工确认	覆盖率阈值、缺陷数量上限、性能指标、审批结论
失败含义	本次运行未通过，按规则重试、续跑或终止	本次发布不放行，需修复后重新评估

两者的衔接点在门禁结果作为流水线阶段的通过条件。质量门禁检查作为流水线中的一个阶段执行，检查通过则流水线继续，检查不通过则按执行规则处置该阶段失败——是中断、通知还是允许人工豁免，由执行规则决定。这样分工后，门禁标准调整不影响流水线编排，执行规则调整也不改变放行标准。流水线与外部平台的对接配置属于工具链集成范畴，不在执行规则的定义范围内。

一个具体例子与常见误解

以下为演示情景，用于串联五类要素。某团队为合并请求配置了一条流水线：开发者推送代码到功能分支并发起合并请求，触发条件限定为目标分支为主干、变更路径包含源码目录，触发人权限限定为项目成员。流水线启动后，静态检查与单元测试并行执行，二者都基于同一份代码且互不依赖；构建阶段在测试通过后串行执行，产出制品供后续阶段使用。集成测试阶段设定三十分钟超时，首次运行因测试环境资源不足失败，规则判定为环境性失败并自动重试一次，重试成功。随后进入生产部署前的人工确认节点，确认人查看测试报告后确认通过，流水线继续完成部署，确认记录留存。若集成测试因断言失败而失败，规则判定为确定性失败，不重试，中断后续阶段，保留日志并通知提交人，该版本标记为失败状态。

围绕执行规则有几个常见误解需要纠正。

把执行规则等同于质量门禁标准：执行规则规定流水线怎么跑，门禁标准规定什么算达标。把覆盖率阈值写进执行规则、把触发条件写进门禁，会让两层职责混乱，调整其一时牵动另一层。
对所有失败一律自动重试：重试只对环境性失败有效。对编译错误、测试断言失败自动重试，既浪费时间，也可能让真实缺陷在多次重试后被偶然通过的结果掩盖。
触发条件只写分支不写路径与权限：只按分支触发，文档修改、配置调整都会触发全量构建；不限定触发人权限，任何人都能手动启动或跳过检查，执行规则就失去了约束力。

把五类要素写清楚并保持与放行判断的边界，流水线才能在无人值守时稳定运行，在出问题时给出明确处置路径。

常见问题

流水线执行规则和发布准入、质量门禁到底怎么分工？

执行规则管运行过程，回答何时启动、按什么顺序跑、超时和失败怎么处置；发布准入与质量门禁管放行判断，回答指标是否达标、是否允许进入下一环境或对外发布。两者的衔接点是门禁检查作为流水线中的一个阶段执行：门禁通过，流水线继续；门禁不通过，按执行规则处置该阶段失败，是中断、通知还是允许人工豁免由执行规则决定。这样分工后，调整门禁阈值不影响流水线编排，调整执行规则也不改变放行标准。

所有失败都适合配置自动重试吗？

不适合。重试只对环境性失败有效，例如网络抖动、临时资源不足、依赖服务短暂不可用，这类失败重试一至两次往往能恢复。编译错误、测试断言失败、配置缺失属于确定性失败，重试只会重复同样的结果，还会浪费时间，甚至让真实缺陷在多次重试后被偶然通过的结果掩盖。规则中应写明可重试的失败类型、重试次数和间隔，避免无限重试。

人工确认节点超时无人处理，默认应该通过还是暂停？

这取决于该节点的风险程度，需要在规则中提前约定。进入生产环境前的发布确认、高风险变更的执行确认，常见做法是超时后保持暂停并提醒确认人，不默认通过，避免无人值守时把未经确认的变更放出去。对时效要求高、且失败代价可控的场景，也可以约定超时后自动取消本次运行，由人重新发起。无论哪种走向，都应留下确认人、确认时间和确认时流水线状态的记录。