代码之家 › 专栏 › 技术社区 › Yogesh

Gitlab CICD-我们可以定义多个工作流规则吗

gitlab-ci gitlab

Yogesh · 技术社区 · 2 年前

我正在创建一个具有两个请求参数的管道。示例脚本如下所示:

stages:          # List of stages for jobs, and their order of execution
   - download
   - execute
variables:
  # Input variables
  BRANCH_REFERENCE:
    value: ""
    description: "This variable will hold value for Branch Reference"
  RELEASE_TYPE:
    value: ""
    description: "Release Type"  
  RUNNER_TAG: "wave"
  TEST_VAR: "TEST"

workflow:
  rules:
    - if: $BRANCH_REFERENCE == "dev"
      variables:
        RUNNER_TAG: "wave-dev"
      when: always
    - if: $BRANCH_REFERENCE == "prd"
      variables:
        RUNNER_TAG: "wave-prd"  
    - if: $RELEASE_TYPE == "pplus"
      variables:
        TEST_VAR: "product_plus.tar.gz"
      when: always
    - if: $RELEASE_TYPE == "pmod"
      variables:
        TEST_VAR: "product.tar.gz"
      when: always  
    - when: always

download-job:   
  stage: download    
  script:
    - echo "Download Stage Starts"
    - echo ${TEST_VAR}
    - echo ${RUNNER_TAG}
    - echo "Download Stage Ends"
    
  tags:
    - $RUNNER_TAG
execute-job:   
  stage: execute    
  script:
    - echo "Execute Stage Starts"
    - echo ${TEST_VAR}
    - echo ${RUNNER_TAG}
    - echo "Execute Stage Ends"
    
  tags:
    - $RUNNER_TAG

在执行管道时,我传递了2个输入参数。根据输入的参数,我必须设置一些可变值。

为此,我尝试使用工作流规则,但它不符合我的要求。

例如,以下是输入参数

BRANCH_REFERENCE = dev
RELEASE_TYPE = pplus

所以在这种情况下,的期望值 RUNNER_TAG 应设置为 波形dev 和 TEST_VAR 到 product_plus.tar.gz .

但它正在为 RUNNER_TAG 到 波形dev 和 TEST_VAR 到“TEST”,因为首先满足了工作流规则中的if条件,然后跳过了其余的if条件。

那么,是否可以将工作流规则用于此类场景?如果没有,那么还有其他方法可以实现这一点吗?

1 回复 | 直到 2 年前

sytech 2 年前

正如你提到的, workflow:rules 将在第一个规则匹配时停止评估,这意味着最多一个 rules:variables: 应用。

就你的情况而言,你 真正地 只需要在中设置用于runner标记的变量 tags: 。其他一切都可以在运行时处理。换句话说:您的其他变量也可以直接在使用合成变量的作业中设置。

在这种情况下,设置所需的逻辑 RUNNER_TAG 可以使用表示 workflow:rules: ,所以您可以执行以下操作:

variables:
  # Input variables
  BRANCH_REFERENCE:
    value: ""
    description: "This variable will hold value for Branch Reference"
  RELEASE_TYPE:
    value: ""
    description: "Release Type"  
  TEST_VAR: "TEST"
  RUNNER_TAG: 
    value: "wave-$BRANCH_REFERENCE"
    expand: true
workflow:
  rules:
   - if: $BRANCH_REFERENCE != "dev" && $BRANCH_REFERENCE != "prd"
     variables:
       RUNNER_TAG: "wave"
   - when: always

before_script: # set all variables at the start of each job
  - |
    if [[ "$RELEASE_TYPE" == "pmod" ]]; then
        export TEST_VAR="product.tar.gz"
    fi
    # ...etc

如果不能使用来表达runner标记或其他变量所需的逻辑 工作流:规则: 通常,对于涉及许多变量的复杂规则,最简单的方法是使用 dotenv artifact 为后续作业设置变量。然后,您可以实现任意设置变量的逻辑。

这也适用于设置中使用的变量 标签: .

set-variables:
  stage: .pre
  script:
    - if [[ "$CI_COMMIT_BRANCH" == "dev" ]]; then echo "RUNNER_TAG=wave-dev" >> vars.env; fi
    - if [[ "$RELEASE_TYPE" == "pplus" ]]; then echo "TEST_VAR=product_plus.tar.gz" >> vars.env; fi
    # etc...
  artifacts:
    reports:
      dotenv: vars.env

job:
  script:
    - echo $CI_RUNNER_TAGS
    - echo $TEST_VAR
  tags:
    - $RUNNER_TAG

但是,如果需要在作业中评估要设置的变量,则这将不起作用 rules: --因为规则是在创建管道时评估的。

另一个解决的局限性 工作流:规则: 是使用 include:rules: 和 每一个 include规则是单独评估的。你可以使用它 conditionally include yml files 声明将与您的配置合并的其他变量。

即使设置用于作业的变量,这也会起作用 规则: 因为包括是在管道创建时处理的。

只要确保你按照你想要的优先顺序确定这些方向,并注意 how include: configurations are merged .

variables:
  BRANCH_REFERENCE: ""

include:
  - local: ./default-variables.yml

  - local: ./dev-variables.yml
    rules:
      - if: $BRANCH_REFERENCE == "dev"

  - local: ./prod-variables.yml
    rules:
      - if: $BRANCH_REFERENCE == "prd"

  - local: ./pplus-variables.yml
    rules:
      - if: $RELEASE_TYPE == "pplus"

  - local: ./pmod-variables.yml
    rules:
      - if: $RELEASE_TYPE == "pmod"
  # etc...