GitHub 是代码托管与协作开发平台，团队通过仓库集成和 Webhook 把提交、合并请求、分支事件关联到 ONES 工作项，再由工作流步骤上的触发器推进状态。本文回答一个具体问题：这类由 GitHub 代码事件触发的状态变化发生后，后置动作是否照常执行。结论依据 ONES 国内版公有云产品手册中关于代码开发事件触发器的描述，私有部署版和具体仓库权限仍需按实际部署核验。
要点总览（TL;DR）
- 会执行。按 ONES 国内版公有云产品手册的描述，由分支创建、合并请求、提交关联这类代码开发事件触发器驱动的状态变化，不执行步骤验证和步骤属性校验，但会执行后置动作。
- 触发器是配置在工作流步骤上的显式条件，仓库集成本身不会自动改变所有状态；状态没有自动推进时，先查触发器是否配在目标步骤上。
- 从提交到状态变化要经过仓库集成、OAuth 授权或手工配置 Webhook、用 #工作项ID 建立关联、事件命中触发器几个环节，任一环节缺失都不会触发后置动作。
- 被跳过的是步骤验证和步骤属性校验这两类准入检查，仓库授权、Webhook 权限、有效工作项编号等前置条件依然成立。
- 私有部署版接入 GitHub 需先联系 ONES 完成基础配置，且不要与接入私有 GitLab 的流程混用。
直接答案：后置动作会执行，被跳过的是步骤校验
会执行。按 ONES 国内版公有云产品手册的描述，由分支创建、合并请求、提交关联这类代码开发事件触发器驱动的状态变化，不执行步骤验证和步骤属性校验，但会执行后置动作。也就是说，工作项状态可以被代码事件推进，后置动作照常运行，而该步骤上配置的验证与必填属性校验不会在这一次流转中拦截。
这里需要把两件事分开看：后置动作属于状态变化之后要执行的处理，触发器流转会继续走；步骤验证和步骤属性校验属于状态变化之前的准入检查，触发器流转会跳过。这个结论只适用于手册描述的代码开发事件触发器，并且需要仓库已集成、触发器已显式配置。
这里的“触发器驱动流转”指什么
触发器是配置在工作项工作流步骤上的代码事件触发条件。手册说明，可为工作项工作流步骤配置分支创建、合并请求和提交关联等事件触发器。它属于工作流步骤配置的一部分，描述的是“当某个代码事件发生时，这个步骤上的工作项状态如何变化”，并非仓库侧的行为。
成立的前提是显式配置。仓库集成到 ONES 之后，提交、合并请求和分支可以与工作项建立关联，但集成本身不会自动改变所有状态。只有把某类代码事件配置为某个工作流步骤的触发器，事件命中后才会触发对应的状态变化。因此，排查“为什么状态没有自动变化”时，先看触发器是否配在了正确的步骤上，再看事件是否真的命中。
一次提交关联到状态变化的完整链路
从代码事件到后置动作，大致经过以下几个环节，每个环节都有各自的依赖条件。
- 完成仓库集成。在配置中心启用代码集成，新增关联仓库，完成 OAuth 认证后选择仓库。这一步需要代码集成配置权限。
- 取得 Webhook 权限。OAuth 用于取得配置仓库 Webhook 的权限；权限不足时需手工配置 Webhook。GitHub 侧提供仓库 Webhook 的创建和管理接口，以 HTTP POST 推送订阅事件，管理接口需要对应仓库的 Webhooks 权限。
- 建立工作项关联。在 commit message 中使用 #工作项ID，一次关联多个工作项时以空格分隔；也可以在合并请求标题或描述中写入 #工作项ID，关联多个工作项。工作项编号须有效，且仓库已关联。
- 事件命中触发器。代码事件到达后，命中工作流步骤上配置的分支创建、合并请求或提交关联触发器，工作项状态随之变化。
- 执行后置动作。状态变化完成后，该步骤配置的后置动作继续执行；同一次流转中，步骤验证和步骤属性校验不执行。
这条链路里，前三步决定事件能否被正确识别并关联到工作项，第四步决定状态是否变化，第五步才是本文问题的答案所在。任何一步缺失，后置动作都不会因为这次代码事件而被触发。
被跳过的校验与仍然生效的约束
触发器流转跳过的是步骤验证和步骤属性校验。这意味着，如果某个步骤原本要求填写某些属性或通过人工验证才能进入，代码事件推进状态时不会在这些检查上停下。团队在设计流程时，需要把这类准入要求放到其他环节，例如在合并请求评审、代码检查或后续人工确认中体现。
以下约束在触发器流转中依然成立：
- 仓库必须已集成到 ONES，并完成 OAuth 认证或手工配置 Webhook。
- Webhook 权限必须足够，权限不足时需手工配置。
- 提交或合并请求中引用的工作项编号必须有效，且仓库已关联。
- 触发器必须显式配置在目标工作流步骤上。
- 使用私有部署版 ONES 接入 GitHub 或公有 GitLab 时，手册要求先联系 ONES 完成基础配置，且不要与接入私有 GitLab 的流程混用。
另外，手册描述一次最多获取 100 个仓库，可按账号拆分关联；这是 ONES 侧的获取范围，并非 GitHub 平台的仓库总上限。移除代码仓关联会停止获取该仓库的新提交数据，历史已获取数据保留。
和手工流转的区别，以及一个常见误解
手工流转和触发器流转走的是同一个工作流步骤，但在校验环节上表现不同。手工操作由人在界面上推进状态，步骤验证和步骤属性校验按配置执行；触发器流转由代码事件推进，这两类校验不执行，后置动作则两者都会执行。可以用一张小表对照：
| 对比项 | 手工流转 | 代码事件触发器流转 |
|---|---|---|
| 步骤验证 | 执行 | 不执行 |
| 步骤属性校验 | 执行 | 不执行 |
| 后置动作 | 执行 | 执行 |
| 触发来源 | 人工操作 | 分支创建、合并请求、提交关联等代码事件 |
常见误解是：既然自动流转跳过了校验，那整条流程规则就都失效了，后置动作大概也不会跑。实际情况是，跳过的只是步骤验证和步骤属性校验这两类准入检查，后置动作仍然执行。把“校验被跳过”理解成“流程全部失效”，会让人误判通知、字段更新等后续处理是否发生，也可能让人误以为可以借自动流转绕开所有管控。更稳妥的做法是明确哪些检查必须由人工或代码评审承担，哪些可以交给触发器后的动作完成。
配置前要确认的条件与验证方法
在把 GitHub 事件接到 ONES 状态流转之前，建议按下面的清单逐项核对，并用一次真实事件观察结果。
- 确认部署版本。本文结论对应 ONES 国内版公有云产品手册的描述；私有部署版需先联系 ONES 完成基础配置，具体版本和仓库权限在实施前确认。
- 确认仓库权限。检查代码集成配置权限、OAuth 授权范围以及仓库 Webhook 权限；权限不足时按手册手工配置 Webhook。
- 确认触发器位置。核对分支创建、合并请求、提交关联触发器是否配置在目标工作流步骤上，避免配到相邻步骤导致状态推进方向不符。
- 确认关联写法。提交信息使用 #工作项ID，多个工作项以空格分隔；合并请求在标题或描述中写入 #工作项ID。
- 做一次端到端验证。用一次真实提交或合并请求触发流转，观察工作项状态是否按预期变化，以及该步骤的后置动作是否产生预期结果，例如通知或字段更新。
- 记录校验差异。把该步骤上原本依赖步骤验证和必填属性的检查，改由评审或后置动作承担，避免自动流转后出现信息缺失。
验证时以可观察的结果为准：状态是否变化、后置动作是否留下痕迹、关联的工作项是否正确。若状态没有变化，依次排查仓库关联、Webhook 权限、工作项编号和触发器配置；若状态变化但后置动作没有预期结果，则检查后置动作本身的配置，而不是假设它被跳过。
常见问题
触发器流转跳过了步骤校验，是不是意味着这条工作流的管控全部失效了？
跳过的范围限于步骤验证和步骤属性校验这两类准入检查。仓库授权、Webhook 权限、工作项编号有效性、触发器配置位置这些前置条件依然成立，后置动作也照常执行。如果某个步骤原本依赖必填属性来保证信息完整，建议把这类要求转移到合并请求评审、代码检查或后置动作中承担，避免自动流转后出现字段缺失。
状态已经自动变了，但预期的通知或字段更新没有出现，应该先查什么？
先检查后置动作本身的配置，而不是假设它被跳过。手册说明触发器驱动的状态变化会执行后置动作，所以没有产生预期结果时，排查方向应放在后置动作的触发条件、执行对象和配置内容上。同时确认这次状态变化确实由代码事件触发器驱动，而非其他途径。
提交里写了 #工作项ID，状态却没有变化，常见原因有哪些？
可以按链路顺序排查：仓库是否已集成到 ONES 并完成 OAuth 认证或手工配置 Webhook；Webhook 权限是否足够；引用的工作项编号是否有效、仓库是否已关联；触发器是否显式配置在目标工作流步骤上。提交信息中一次关联多个工作项时以空格分隔，合并请求则在标题或描述中写入 #工作项ID。
私有部署版接入 GitHub，配置流程和公有云一样吗？
不完全一样。手册要求使用私有部署版 ONES 接入 GitHub 或公有 GitLab 时，先联系 ONES 完成基础配置，并且不要与接入私有 GitLab 的流程混用。具体版本和仓库权限建议在实施前与 ONES 确认，再按核对清单做端到端验证。
关联仓库数量有上限吗，解除关联后历史提交数据会丢吗？
手册描述一次最多获取 100 个仓库，可按账号拆分关联，这是 ONES 侧的获取范围，并非 GitHub 平台的仓库总上限。移除代码仓关联会停止获取该仓库的新提交数据，历史已获取的数据保留。
官方参考资料
- GitHub/公有 GitLab（ONES）
