Gitlab CI/CD: rules和only_gitlab-ci only

对比rules和only

rules 和 only 都是在 GitLab CI/CD 配置中用于控制作业（job）何时执行的关键字，但它们之间有一些不同之处：

1. only 关键字：

   only 关键字用于定义在特定情况下触发作业的条件。你可以指定一系列触发条件，只有当至少一个条件匹配时，作业才会被触发执行。only 通常用于根据分支、标签、变量等来设置作业的触发条件。例如：

   only:
     - branches  # 触发所有分支上的作业
     - tags      # 触发所有标签上的作业
     - schedules # 触发通过计划任务（Scheduled pipelines）触发的作业
   1
   2
   3
   4

2. rules 关键字：

   rules 关键字是在较新的GitLab 12.3 版本引入的功能，它提供了更灵活和复杂的条件设置。通过 rules，你可以设置一个或多个条件，以及根据条件来定义作业是否应该执行，何时执行，以及应该如何执行。rules 支持更多的条件判断和更复杂的逻辑。例如：

   rules:
     - if: '$CI_COMMIT_BRANCH == "main"'
       when: manual
     - exists:
         - file.txt
       when: on_success
   1
   2
   3
   4
   5
   6

   在这个例子中，第一个规则是：只有在 main 分支上时，作业将需要手动触发。第二个规则是：只有当指定的文件 file.txt 存在时，作业在成功状态下才会自动触发。

总的来说，only 更简单，适用于基本的分支、标签和计划任务触发条件。而 rules 则更灵活，可以进行更复杂的条件判断，并且能够更精细地控制作业的触发和执行。如果你的 GitLab 版本支持 rules，那么在编写配置时可以考虑使用 rules 来获得更多的控制权。
而gitlab官方似乎也更推荐于rules,当前版本是16.3了。
文档地址

对比only和rules写法

分支-only:

  only:
    refs:
      - main
1
2
3

分支-rules:

  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: on_success
1
2
3

标签-only:

  only:
    - /^dev-.*$/
1
2

标签-rules:

  rules:
    - if: '$CI_COMMIT_TAG =~ /^dev-/'
      when: on_success
1
2
3

workflow和rules的应用：

虽然这个示例有点复杂奇怪，但是主要是想用rules和workflow在多个不同环境下去deploy。
我先只定义一个job就叫test, 然后定义了一下变量COMMIT_REF,TEST_PATH和不同tag下面的ENV。然后下面有echo输出。意思是会根据打不同的tag标签就会执行相同的job，而path和port不一样。

variables:
  COMMIT_REF: "$CI_COMMIT_TAG"
  TEST_PATH: "test/ghkg/$ENV/$COMMIT_REF"
workflow:
  rules:
    - if: '$CI_COMMIT_TAG =~ /^dev-/'
      variables:
        ENV: "dev"
        TEST_PATH: "test01/$ENV/$COMMIT_REF"
        SERVER_PORT: "8081"
    - if: '$CI_COMMIT_TAG =~ /^prod-/'
      variables:
        ENV: "prod"
        TEST_PATH: "test02/$ENV/$COMMIT_REF"
        SERVER_PORT: "8082"
stages:
  - test
test:
  stage: test
  tags:
    - shell
  environment:
    name: $ENV
  script:
    - export
    - echo "$ENV"
    - echo "cd $TEST_PATH"
    - echo "java -jar demo.jar  --spring.profiles.active=$ENV  --server.port=$SERVER_PORT"
    - echo "test end" # 以上命令其实根据根据环境不同，变量不同来运行同一个job
  artifacts:
    paths:
      - /*
    expire_in: 1 hour
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

比如我打个prod-0.0.1标签：

后面这里还有一种情况:
注意条件请不要改成branch和tag同时判断：

  rules:
    - if: '$CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TAG =~ /^dev-/'
1
2

在 GitLab CI/CD 中，$CI_COMMIT_BRANCH 和 $CI_COMMIT_TAG 是两个不同的预定义环境变量，它们分别用于获取当前提交的分支名和标签信息。这两个变量在不同的情况下会有不同的取值：

1. 当你在进行提交（push）操作时，CI_COMMIT_BRANCH 可能会有值，表示当前提交所在的分支。而此时，CI_COMMIT_TAG 通常为空，因为你没有创建标签。
2. 当你在创建并推送一个标签时，CI_COMMIT_TAG 可能会有值，表示当前提交是一个标签。此时，CI_COMMIT_BRANCH 通常为空，因为标签是在分支上的特定提交上创建的，而不是在分支上。

通常情况下，$CI_COMMIT_BRANCH 和 $CI_COMMIT_TAG 是互斥的，不会同时都有值。这是因为分支和标签是不同的 Git 概念，一个提交要么在分支上，要么是一个标签，而不可能同时既是分支又是标签。

可以用这个例子打印一下看一下：
意思是提交到main会触发一次deploy又或者提交一个tag:dev-*也会触发deploy，COMMIT_REF变量我先改成了$CI_COMMIT_REF_NAME。

variables:
  COMMIT_REF: "$CI_COMMIT_REF_NAME"
  TEST_PATH: "test/ghkg/$ENV/$COMMIT_REF"
workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      variables:
        ENV: "local"
        TEST_PATH: "test00/$ENV/$COMMIT_REF"
        SERVER_PORT: "8080"
    - if: '$CI_COMMIT_TAG =~ /^dev-/'
      variables:
        ENV: "dev"
        TEST_PATH: "test01/$ENV/$COMMIT_REF"
        SERVER_PORT: "8081"
stages:
  - test
test:
  stage: test
  tags:
    - shell
  environment:
    name: $ENV
  script:
    - export
    - echo "$CI_COMMIT_REF_NAME"
    - echo "$CI_COMMIT_TAG"
    - echo "$CI_COMMIT_BRANCH"
    - echo "$ENV"
    - echo "cd $TEST_PATH"
    - echo "java -jar demo.jar  --spring.profiles.active=$ENV  --server.port=$SERVER_PORT"
    - echo "test end" # 以上命令其实根据根据环境不同，变量不同来运行同一个job
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

如果同时满足两个条件，是在main分支上打dev-标签，就会触发两次deploy。