0

In the docs I find many OR examples:

job:
  script: echo "This job does NOT create double pipelines!"
  rules:
    - if: ($CI_COMMIT_BRANCH  == $CI_DEFAULT_BRANCH || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE

Is there a way to do something like this pseudo code:

job:
  script: echo "This job does NOT create double pipelines!"
  rules:
    - if: ($CI_COMMIT_BRANCH in ($CI_DEFAULT_BRANCH, "develop") && $MY_VARIABLE
safex
  • 2,398
  • 17
  • 40

2 Answers2

2

No, in is not an available operator. However, regex offers an equivalent with patterns like (a | b) so $FOO in (a, b) could be expressed with a regex rule like $FOO =~ /(a | b)/

So something like this might work for you:

# ...
variables:
  rules:
    - if: '$CI_COMMIT_BRANCH =~ /(main|develop)/ && $MYVAR'

One caveat, however, is that because of unresolved issues in GitLab's regex and variable handling, you can't use variables directly in a pattern. So you have to statically declare your default branch as above in this case.

In cases where you must use a variable, your first example is probably the most reasonable approach.

sytech
  • 29,298
  • 3
  • 45
  • 86
1

TLDR: tested not working (kept for reference of discussion, to be removed later)


I came to a similar conclusion like sytech to use a regular expression, and also considered similar to Gitlabs remark with the variables as this is a common problem.

Therefore I checked with the regular expression specification in use and consider the problem greatly reduced thanks to \Q...\E support in RE2¹:

job:
  script: echo "This job does NOT create double pipelines!"
  rules:
    - if: ($CI_COMMIT_BRANCH =~ /^(\Q$CI_DEFAULT_BRANCH\E|develop)$/ && $MY_VARIABLE

This syntax allows to use branch names that contain slashes / as well, e.g. fix/me/later (not that I want to promote them, this is just a pretty silly example).

If you follow branch naming rules in git², you should not run into this kind of problem anyway.

hakre
  • 193,403
  • 52
  • 435
  • 836
  • 1
    Does this actually work? My understanding is the problem in GitLab is more about the variable interpolation/expansion behavior. GitLab won't expand variables inside of the re expression so only `$CI_COMMIT_BRANCH` and `MY_VARIABLE` get expanded, so the expression comes out something like `branchname =~ /^(\Q$CI_DEFAULT_BRANCH\E|develop)$/ && variable_value` after interpolation -- that is `CI_DEFAULT_BRANCH` is never understood to be the value of this predefined variable. But maybe my understanding there is not correct. – sytech May 26 '23 at 16:51
  • Isn't the interpolation on word boundaries? As the variable name is properly terminated with a symbol (and starts with the `$`) I was under the impression this must work, but now as you comment on it I should run a test-case... @sytech – hakre May 26 '23 at 19:58
  • @sytech: you're right, I stand corrected, it does not work. unfortunately. Wondering a bit why the substitution / expansion is that limited, but nevertheless, doesn't work. – hakre May 26 '23 at 20:10