Newbie need help using rules

How to Use GitLab
1

Hi,

I thought I understood “rules”:

int-build:
  tags:
    - internet
  stage: build
  artifacts:
    paths:
      - gitops/
    expire_in: 1 hrs
  rules:
    - if: '$CI_COMMIT_BRANCH == "Integration" && $CI_COMMIT_TAG =~ "/^$/"'
      changes: 
       - bs-portal/bsp-project/bsp-core/trunk/**/*
       - bs-portal/bsp-project/bsp-extern/trunk/**/*
    - when: never
  script:
    - ...

The job only runs if there are changes on the “Integration” branch and the changes relate to the paths.

But when I configure a scheduler for the “Integration” branch, gitlab performs this job every time the scheduler is run. My expectation is that in the case of “Scheduler” the job will not be executed either.
What is the logic behind this?

I know there is:
if: '$ CI_PIPELINE_SOURCE == "schedule"'

but what is the idea behind that “scheduler” apparently has to be handled separately?

Thanks for Your time,
Torsten

2

Hi @torsten-liermann

Can I just ask, have you tested this with “normal” pipelines, rather than scheduled ones? And also, what’s the intention behind this clause in your rules: $CI_COMMIT_TAG =~ "/^$/"?

Thanks,

Sarah

1 Like
3

Hi Sara,

I’ve tried hundreds of variations over the past few days to understand gitlab.

The pipeline should not run in the case of tagging, therefore

$ CI_COMMIT_TAG = ~ "/ ^ $ /"?

Scheduler is the next step in my development and I am surprised that the rules do not prevent the scheduler. I had already posted other small stumbling blocks here, but received no response.

I noticed you positively here with your answers. Thanks!
greetings from Munich

4

Hi @torsten-liermann

OK, I’m not sure if I’ve correctly understood what you’re trying to do, but if you want pipelines to run on the integration branch, when those files are changed, but not when a tag has been pushed, I would do that like this:

int-build:
  ...
  rules:
    - if $CI_COMMIT_TAG:
      when: never
    - if: $CI_COMMIT_BRANCH == "Integration"
      changes: 
        - bs-portal/bsp-project/bsp-core/trunk/**/*
        - bs-portal/bsp-project/bsp-extern/trunk/**/*
      when: on_success
    - when: never
  script:
    - ...

Part of this refactoring is just to avoid the use of Bash logic wherever possible, which makes the YAML a bit clearer IMO.

If you only want this to happen on a scheduled pipeline, you could say:

  rules:
    - if $CI_COMMIT_TAG:
      when: never
    - if: $CI_PIPELINE_SOURCE == "schedule" && $CI_COMMIT_BRANCH == "Integration"
      changes: 
        - bs-portal/bsp-project/bsp-core/trunk/**/*
        - bs-portal/bsp-project/bsp-extern/trunk/**/*
      when: on_success
    - when: never

However, when you set the schedule up, you will also specify the branch that the schedule should run on, so you don’t necessarily need the && $CI_COMMIT_BRANCH ... there, unless perhaps you have different scheduled pipelines running on different branches.

If you NEVER want to run a pipeline when a tag is pushed, you can add this somewhere at the top-level of your .gitlab-ci.yml file:

workflow:
     rules:
         - if: $CI_COMMIT_TAG
           when: never
         - when: always

Personally, I would also have:

workflow:
     rules:
         # First clause here is new
         - if: $CI_MERGE_REQUEST_ID
           when: never
         - if: $CI_COMMIT_TAG
           when: never
         - when: always

Because GitLab will run two pipelines for every push to a branch with an MR, and I only want the “branch” pipeline to run, not the “mr” pipeline.

Hopefully that’s enough to get you started!

Sarah

1 Like
5

Thanks Sarah! I have included your code snippet in my show case:

int-build:
  ...
  rules:
    - if $CI_COMMIT_TAG:
      when: never
    - if: $CI_COMMIT_BRANCH == "Integration"
      changes: 
        - bs-portal/bsp-project/bsp-core/trunk/**/*
        - bs-portal/bsp-project/bsp-extern/trunk/**/*
      when: on_success
    - when: never
  script:
    - ...

And my question is still this: why is the job running when the scheduler is running. What is the logic behind this?

6

Is the scheduled pipeline running the Integration branch, and are there changes on that branch in the two directories you’ve listed?

7

No Changes. For test purposes, I run the scheduler every 5 minutes. “Your” job starts again and again.
It’s not that dramatic. I just want to understand.

8

This wasn’t obvious to me, but I found the answer in the docs:

You should use rules: changes only with branch pipelines or merge request pipelines . You can use rules: changes with other pipeline types, but rules: changes always evaluates to true when there is no Git push event. Tag pipelines, scheduled pipelines, and so on do not have a Git push event associated with them. A rules: changes job is always added to those pipelines if there is no if: that limits the job to branch or merge request pipelines.

9

Thanks, Sarah! None of the examples of Mono Repo say a word about it.

1 Like