對比rules和only
rules 和 only 都是在 GitLab CI/CD 配置中用于控制作業(yè)（job）何時執(zhí)行的關(guān)鍵字，但它們之間有一些不同之處：
-
only關(guān)鍵字：only關(guān)鍵字用于定義在特定情況下觸發(fā)作業(yè)的條件。你可以指定一系列觸發(fā)條件，只有當(dāng)至少一個條件匹配時，作業(yè)才會被觸發(fā)執(zhí)行。only通常用于根據(jù)分支、標(biāo)簽、變量等來設(shè)置作業(yè)的觸發(fā)條件。例如：only: - branches # 觸發(fā)所有分支上的作業(yè) - tags # 觸發(fā)所有標(biāo)簽上的作業(yè) - schedules # 觸發(fā)通過計劃任務(wù)（Scheduled pipelines）觸發(fā)的作業(yè) -
rules關(guān)鍵字：rules關(guān)鍵字是在較新的GitLab 12.3 版本引入的功能，它提供了更靈活和復(fù)雜的條件設(shè)置。通過rules，你可以設(shè)置一個或多個條件，以及根據(jù)條件來定義作業(yè)是否應(yīng)該執(zhí)行，何時執(zhí)行，以及應(yīng)該如何執(zhí)行。rules支持更多的條件判斷和更復(fù)雜的邏輯。例如：rules: - if: '$CI_COMMIT_BRANCH == "main"' when: manual - exists: - file.txt when: on_success在這個例子中，第一個規(guī)則是：只有在
main分支上時，作業(yè)將需要手動觸發(fā)。第二個規(guī)則是：只有當(dāng)指定的文件file.txt存在時，作業(yè)在成功狀態(tài)下才會自動觸發(fā)。
總的來說，only 更簡單，適用于基本的分支、標(biāo)簽和計劃任務(wù)觸發(fā)條件。而 rules 則更靈活，可以進行更復(fù)雜的條件判斷，并且能夠更精細地控制作業(yè)的觸發(fā)和執(zhí)行。如果你的 GitLab 版本支持 rules，那么在編寫配置時可以考慮使用 rules 來獲得更多的控制權(quán)。
而gitlab官方似乎也更推薦于rules,當(dāng)前版本是16.3了。
文檔地址
對比only和rules寫法
分支-only:
only:
refs:
- main
分支-rules:
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: on_success
標(biāo)簽-only:
only:
- /^dev-.*$/
標(biāo)簽-rules:
rules:
- if: '$CI_COMMIT_TAG =~ /^dev-/'
when: on_success
workflow和rules的應(yīng)用：
雖然這個示例有點復(fù)雜奇怪，但是主要是想用rules和workflow在多個不同環(huán)境下去deploy。
我先只定義一個job就叫test, 然后定義了一下變量COMMIT_REF,TEST_PATH和不同tag下面的ENV。然后下面有echo輸出。意思是會根據(jù)打不同的tag標(biāo)簽就會執(zhí)行相同的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" # 以上命令其實根據(jù)根據(jù)環(huán)境不同，變量不同來運行同一個job
artifacts:
paths:
- /*
expire_in: 1 hour
比如我打個prod-0.0.1標(biāo)簽：
后面這里還有一種情況:
注意條件請不要改成branch和tag同時判斷：
rules:
- if: '$CI_COMMIT_BRANCH == "main" && $CI_COMMIT_TAG =~ /^dev-/'
在 GitLab CI/CD 中，$CI_COMMIT_BRANCH 和 $CI_COMMIT_TAG 是兩個不同的預(yù)定義環(huán)境變量，它們分別用于獲取當(dāng)前提交的分支名和標(biāo)簽信息。這兩個變量在不同的情況下會有不同的取值：
- 當(dāng)你在進行提交（push）操作時，CI_COMMIT_BRANCH 可能會有值，表示當(dāng)前提交所在的分支。而此時，CI_COMMIT_TAG 通常為空，因為你沒有創(chuàng)建標(biāo)簽。
- 當(dāng)你在創(chuàng)建并推送一個標(biāo)簽時，CI_COMMIT_TAG 可能會有值，表示當(dāng)前提交是一個標(biāo)簽。此時，CI_COMMIT_BRANCH 通常為空，因為標(biāo)簽是在分支上的特定提交上創(chuàng)建的，而不是在分支上。
通常情況下，$CI_COMMIT_BRANCH 和 $CI_COMMIT_TAG 是互斥的，不會同時都有值。這是因為分支和標(biāo)簽是不同的 Git 概念，一個提交要么在分支上，要么是一個標(biāo)簽，而不可能同時既是分支又是標(biāo)簽。
可以用這個例子打印一下看一下：
意思是提交到main會觸發(fā)一次deploy又或者提交一個tag:dev-*也會觸發(fā)deploy，COMMIT_REF變量我先改成了$CI_COMMIT_REF_NAME。文章來源：http://www.zghlxwxcb.cn/news/detail-770233.html
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" # 以上命令其實根據(jù)根據(jù)環(huán)境不同，變量不同來運行同一個job
如果同時滿足兩個條件，是在main分支上打dev-標(biāo)簽，就會觸發(fā)兩次deploy。文章來源地址http://www.zghlxwxcb.cn/news/detail-770233.html
到了這里，關(guān)于Gitlab CI/CD: rules和only的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
