触发流水线

文章内容

触发流程
触发事件
事件分类
分支匹配
事件与配置文件

触发流程

以 git push 事件为例介绍代码如何触发流水线执行的过程：

提交代码并 push 到 CODING 代码托管远端服务器。
云原生构建平台解析 push 事件触发请求，分析出 repository、event、branch、sha 等信息。
从代码项目中的分支或 sha 值中获取配置文件 (.coding-ci.yml)，并从中解析出 event 对应的流水线配置。
执行流水线。

若流水线中包含多个 event，如创建分支包含 branch.create、push，对应的流水线会被并行执行。单流水线多 event 示例：

master:
  push:
    - stages:
        - name: echo
          script: echo 1
  branch.create:
    - stages:
        - name: echo
          script: echo 2

触发事件

流水线通过事件触发，事件可以分为：Git 事件、自定义事件两种类型。

事件分类

Git 事件

Git 事件 是指远端仓库操作触发的事件。

目前支持以下事件：

push

分支 push 事件。

可通过环境变量 CODING_IS_NEW_BRANCH 判断是否是新建分支。

branch.create

分支创建事件，同时会触发 push 事件。

branch.delete

分支删除事件。因为流水线运行时分支已被删除，流水线配置文件将改为选用默认分支的最新版本。

merge_request

分支合并事件，合并请求创建或者更新（源分支发生改动）时触发。

mergeable

合并请求处于可合并时触发事件。默认情况下，当合并请求评审通过且合并状态检查已成功时，该合并请求将进入可合并状态。

merged

分支合并完成事件。

a 分支合并到 b 分支，会触发 b 分支下的 merged、push 事件。

tag_push

tag push 事件

示例：

v*:
  tag_push:
    - stages:
        - name: echo
          # CODING_BRANCH 值为tag名称
          script: echo $CODING_BRANCH

自定义事件

由 coding-ci:apply、coding-ci:trigger 等内置任务或 CODING OPENAPI 等事件触发。事件名必须为 api_trigger 或者 api_trigger_ 开头，如 api_trigger_test。

示例：

$:
  api_trigger_check:
    - stages:
      - name: echo
        # CODING_BRANCH 值为tag名称
        script: echo hello in api_trigger_check

分支匹配

glob 模式匹配

glob 模式简介。

分支名称支持通过 glob 模式匹配，如：

dev/*:
 push:
   - push_pipeline
master/*:
 push:
   - push_pipeline    
**:
 push:
   - push_pipeline   
$:
  push:
    - push_pipeline

匹配策略

分支匹配时，会分阶段，按优先级匹配，只有没有匹配结果时，才会尝试下一阶段的匹配。

一共分为两个阶段，他们的优先级为：

glob 匹配
$ 匹配

特殊字符 $ 下面可以放置一些没有分支可以挂靠的事件，如 tag_push、api_trigger。

如果多个 glob 规则都匹配，所有的规则会被并行执行。

事件与配置文件

下文列举了在各个事件中，流水线如何选择使用配置文件中的内容。需要额外关注的是 merge_request 事件，它的选择相对复杂一些：

对于 push 事件，会从当前 Commit 节点读取配置文件。
对于 branch.delete 事件，因为分支已删除，会从默认分支读取配置文件。
对于 tag_push 事件，会从当前 tag 处读取配置文件。
对于 merge_request 事件，有源分支和目标分支，情况稍微复杂，具体策略如下：
1. 配置文件：取源分支
  1. 配置文件未修改：即源分支和目标分支对比，配置文件未发生修改
  2. 配置文件有修改：源分支需要包含目标分支的变更（即 rebase 或 merge 过目标分支）
  3. 1 和 2 都不满足时，说明源分支落后目标分支，拒绝构建，此时，需更新源分支，包含目标分支已经发生的变更
2. 源代码：采用模拟合并，然后在合并后的源代码上进行构建。将问题暴露在merge_request，避免遗留到合并后的目标分支。
对于 mergeable 事件，会从源分支读取配置文件。
对于 merged 事件，同 push 事件，取目标分支的配置文件。
自定义事件，参考 coding-ci:apply、coding-ci:trigger

问题反馈 >

2023-02-21最近更新

感谢反馈有用

感谢反馈没用