Coding-CI

分支事件

# 事件驱动

云原生构建 流水线通过事件触发。以 push 事件为例介绍从代码变更到流水线执行的过程：

  1. 用户提交代码并 push 到远端服务器（Coding）。

  2. 云原生构建 收到 push 事件触发请求，分析出 repository、event、branch 等信息。

  3. 云原生构建 从 repository 仓库 branch 分支获取配置文件(默认 .coding-ci.yml )，从中解析出 event 对应流水线配置。

  4. 云原生构建 执行流水线。

若命中多个 event，如创建分支命中 branch.create 和 push，配置文件中对应事件会被视作不同 构建 并行执行。

多 event 示例：

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

# Git 事件

Git 事件是由远端代码操作触发的事件。

# push

分支 push 事件。

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

# branch.create

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

# branch.delete

分支删除事件。

流水线配置可以挂靠在分支名或 $ 上。

因流水线运行时分支已删除，使用主分支的配置文件。

示例：

dev/1:
  branch.delete:
    - stages:
        - name: echo
          # CODING_BRANCH 值为删除的分支
          script: echo $CODING_BRANCH
$:
  branch.delete:
    - stages:
        - name: echo
          # CODING_BRANCH 值为删除的分支
          script: echo $CODING_BRANCH

# merge_request

分支合并事件，由 mr 的创建以及源分支 push 触发。同 merge_request.target 的区别参考配置文件。

# merge_request.target

分支合并事件，由 mr 的创建以及源分支 push 触发。同 merge_request 的区别参考配置文件。

# mergeable

仓库设置 开启状态检查，mr CI 状态变更或评审通过，无阻塞可合并时触发。

# merged

分支合并完成事件。

TIP

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

# tag_push

tag push事件。

示例：

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

# 自定义事件

事件名为 api_trigger 或者 api_trigger_ 开头，如 api_trigger_test。

自定义事件有以下两种触发方式

  1. 由coding-ci:apply触发
  2. 由coding-ci:trigger触发

# 定时任务事件

由定时器触发，详情参考定时器。

# 分支匹配

# glob 模式匹配分支

分支名称支持通过 glob 模式匹配（什么是 glob 匹配？ (opens new window)），如：

# 匹配以 dev/ 开头的所有分支
"dev/*":
  push:
    - push_pipeline

# 匹配 master 或 dev 分支
"(master|dev)":
  push:
    - push_pipeline

# 匹配除 master 和 dev 以外的所有分支
"**/!(master|dev)":
  push:
    - push_pipeline

# 匹配所有分支
"**":
  push:
    - push_pipeline

# 兜底，匹配没有 glob 匹配的分支
"$":
  tag_push:
    - push_pipeline

# 匹配策略

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

  1. glob 匹配分支名
  2. $ 兜底匹配所有未被 glob 匹配的分支

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

# 配置文件版本选择

因为配置文件是在项目仓库中，受到 Git 仓库版本控制的，所以配置文件自然也会有多个版本， 在某次构建中，使用哪个版本的配置文件，应该是开发者必须了解的信息。幸运的是， 云原生构建 的机制是非常符合直觉的，在绝大多数场景下，开发者都不需要额外关心这件事。

下面列举在各个事件中，云原生构建 是如何选择使用哪个配置文件中的内容的，需要额外关注的是 merge_request 事件，它的选择相对复杂一些：

  1. 对于 push、branch.create 事件，会从当前 Commit 节点读取配置文件。
  2. 对于 branch.delete 因为分支已删除，会从主分支读取配置文件。
  3. 对于 tag_push 事件，会从当前 tag 处读取配置文件。
  4. 对于 merge_request、mergeable 事件，有源分支和目标分支，取预合并后的配置文件
  5. 对于 merged 事件，取合并后的配置文件
  6. 对于 merge_request.target 事件，取合并前目标分支的配置文件。
  7. 自定义事件，参考coding-ci:apply、coding-ci:trigger。
  8. 定时任务事件，从指定的分支读取配置文件。