![cover](https://img-blog.csdnimg.cn/8956883f265447e1a4d6256297c6f2d9.jpeg)
Gitlab CI/CD: rules和only
其实主要是想写workflow和rules, 做的笔记太多了,就全加上了
对比rules和only
rules
和 only
都是在 GitLab CI/CD 配置中用于控制作业(job)何时执行的关键字,但它们之间有一些不同之处:
-
only
关键字:only
关键字用于定义在特定情况下触发作业的条件。你可以指定一系列触发条件,只有当至少一个条件匹配时,作业才会被触发执行。only
通常用于根据分支、标签、变量等来设置作业的触发条件。例如:only: - branches # 触发所有分支上的作业 - tags # 触发所有标签上的作业 - schedules # 触发通过计划任务(Scheduled pipelines)触发的作业
-
rules
关键字:rules
关键字是在较新的GitLab 12.3 版本引入的功能,它提供了更灵活和复杂的条件设置。通过rules
,你可以设置一个或多个条件,以及根据条件来定义作业是否应该执行,何时执行,以及应该如何执行。rules
支持更多的条件判断和更复杂的逻辑。例如:rules: - if: '$CI_COMMIT_BRANCH == "main"' when: manual - exists: - file.txt when: on_success
在这个例子中,第一个规则是:只有在
main
分支上时,作业将需要手动触发。第二个规则是:只有当指定的文件file.txt
存在时,作业在成功状态下才会自动触发。
总的来说,only
更简单,适用于基本的分支、标签和计划任务触发条件。而 rules
则更灵活,可以进行更复杂的条件判断,并且能够更精细地控制作业的触发和执行。如果你的 GitLab 版本支持 rules
,那么在编写配置时可以考虑使用 rules
来获得更多的控制权。
而gitlab官方似乎也更推荐于rules
,当前版本是16.3了。
文档地址
对比only和rules写法
分支-only:
only:
refs:
- main
分支-rules:
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: on_success
标签-only:
only:
- /^dev-.*$/
标签-rules:
rules:
- if: '$CI_COMMIT_TAG =~ /^dev-/'
when: on_success
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
比如我打个prod-0.0.1标签:
后面这里还有一种情况:
注意条件请不要改成branch和tag同时判断:
rules:
- if: '$CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TAG =~ /^dev-/'
在 GitLab CI/CD 中,$CI_COMMIT_BRANCH 和 $CI_COMMIT_TAG 是两个不同的预定义环境变量,它们分别用于获取当前提交的分支名和标签信息。这两个变量在不同的情况下会有不同的取值:
- 当你在进行提交(push)操作时,CI_COMMIT_BRANCH 可能会有值,表示当前提交所在的分支。而此时,CI_COMMIT_TAG 通常为空,因为你没有创建标签。
- 当你在创建并推送一个标签时,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
如果同时满足两个条件,是在main分支上打dev-标签,就会触发两次deploy。
![Logo](https://devpress.csdnimg.cn/79de2bf0b7994defa4242ef90d5513fa.jpg)
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)