Help getting pipeline to run

GitLab CI/CD
,
1

I’m trying to create a pipeline for my repo that triggers child pipelines in subdirectories based on whether anything changed in those directories (and reusing as much code as possible). I thought I had something working, but because I only had one test case, I didn’t realize that all the child pipelines were getting triggered regardless of whether or not there were any changes in the respective directories. I’ve since managed to get it to not trigger any pipelines at all. I thought perhaps that was because I was making changes only to the top-level .gitlab-ci.yml, but even making a dummy change in one of the directories didn’t get anything to run.

My .gitlab-ci.yml currently looks like this:

workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
      when: never
    - when: always

stages:
  - trigger

.base:
  stage: trigger
  trigger:
    include: $DIRECTORY/.gitlab-ci.yml
    forward:
      pipeline_variables: true
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        compare_to: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
        paths:
          - $DIRECTORY/*
      when: always
    - if: $CI_COMMIT_BRANCH
      changes:
        compare_to: $CI_DEFAULT_BRANCH
        paths:
          - $DIRECTORY/*
      when: always

alice:
  extends: .base
  variables:
    DIRECTORY: home/alice

bob:
  extends: .base
  variables:
    DIRECTORY: home/bob

This is on gitlab.com, and the pipeline editor is satisfied that the syntax is correct. I added the compare_to thinking that perhaps it was only detecting changes against the previous commit (since the default doesn’t seem to be defined), but the dummy change I made suggests that’s not what the problem is.

Sadly, my usual debugging techniques (like setting CI_DEBUG_TRACE) are useless here, since if there’s no pipeline to run, no tracing code will get executed. I’ve been wishing for something in the UI that would explain each check it makes in its decision as to whether to run any given job, so it could tell me that $CI_PIPELINE_SOURCE isn’t what I’m expecting, or the when and if statements are combining in a way I’m not expecting, etc.

Would the validity of the child pipelines have anything to do with it, or would they blow up (or decline to run) independently?

My next step is to extract this into a repo where running jobs is without consequence and try to build it up piece by piece, but if anyone has any insight, I’d love a short-cut!

1 Like
2

Turns out compare_to doesn’t interpolate variables, so who knows what it was comparing against.

Is there an explanation anywhere of why new keywords are being added without this ability? It seems like you’d need a good reason not to allow it, rather than having to go back and add it piecemeal, but perhaps there’s something tricky about that?

1 Like
3

Thinking on this a bit further, just hard-coding master or main doesn’t seem like a good workaround, because even using $CI_DEFAULT_BRANCH for a branch pipeline or $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME for a merge request pipeline isn’t right. You don’t want to compare against the head of the branch, but at the merge base with the current branch. Otherwise, matching changes in the comparison branch will trigger spurious pipelines on every single push to the branch or MR even in a completely unrelated area. :frowning: AFAIK, there’s no predefined variable with that information in it, is there?

1 Like