GitlabCI配置only-except的坑

背景

之前在配置 .gitlab-ci.yml 时，当我们需要制定某个任务在特定情况执行时会这么配置：

job:
  only:
    - /^release-.*$/

这段代码的意图是当触发的 branch 和 tag 满足正则时则执行这个任务。

类似的配置在我们公司的 Gitlab（版本 13.2）中能与预期一致正常执行。

但我在 gitlab.com 中部署自己的博客时发现，当我创建满足条件的 tag 时 CI 怎么都无法触发。

排查问题

排查官方文档后发现官方是这么写的：

其中第二项介绍了正则的使用方式：

• Regular expressions that match against branch names, for example /^feature-.*/.

文档中明确说明了正则只支持对 branch 的匹配，并没有对 tags 的匹配，这也是我创建 tag 无法触发 CI 的原因。

那为什么我在公司里的项目中可以正确触发呢？

我检查了公司私有化部署的 Gitlab 版本，发现版本号是 13.2，官方文档中并没有该版本的文档，接近的只有 13.12 和 12.10 版本。

对比 13.12 和 12.10 版本之后发现，13.12 版本与最新版本一致，文档中说明只能匹配 branch，而 12.10 版本的文档描述则不同：

文档里有两点信息，一是 only/expect 即将被废弃，二是所有的 refs 都能被匹配。

下面的例子也印证了可以匹配 tags：

由此我们可以得出 gitlab 在升级到13.12版本后对 only/expect 的语法进行了修改，现在只能匹配 branch name 而不能匹配 tag name。

修改 .gitlab-ci.yml

方法一：使用 only: variables / except: variables

可以直接使用全局系统变量 CI_COMMIT_REF_NAME 进行判断，该变量对于 branch 和 tag 都能获取到相应的值。

job1:
  only:
    variables:
      - $CI_COMMIT_REF_NAME =~ /^release-.*$/

方法二：使用 rules

官方推荐使用 rules 进行任务执行条件的判断：

job1:
  rules:
    - if: $CI_COMMIT_REF_NAME =~ /^release-.*$/

使用 changes 可以对修改的文件类型进行判断

在查阅文档的过程中还发现另一种非常有用的方式，即对修改文件类型的校验，这种方式非常适合用来做基础镜像的构建，例如：

job1:
  rules:
    - changes:
        - Dockerfile
        - package.json

注意事项：经测试，如果多次 commit 合并推送到远程仓库，只有触发 CI 的最后一次提交的文件会被检测。所以如果有对依赖文件的修改，保证修改后立刻推送一次远程仓库。