GitLab pipeline reruns on JSON file change despite excluding bot user - need assistance

GitLab CI/CD
1

I’ve set up a GitLab pipeline to run when a specific JSON file changes. After the pipeline completes successfully, it attempts to run again automatically. To prevent this, I added a configuration to exclude the bot user from triggering the pipeline. However, this configuration doesn’t seem to work as expected.

I’ll also mention I’ve tried several variations of the above. I can see the BOT_USER variable is correct, it matches the GITLAB_USER_LOGIN. I have no way of proving that the evaluation is either True or False. It’s madness.

What are you seeing, and how does that differ from what you expect to see?

I see the pipeline running multiple times, even after a successful run. I expect it to run only once when the JSON file changes. The repeated run, especially after excluding the bot user, is unexpected.

What version are you on? Are you using self-managed or GitLab.com?

GitLab: Self managed 14.3.6-ee
Runner: 15.11.0

variables:
  BOT_USER: "project_${CI_PROJECT_ID}_bot"

on_all:
  script:
    - echo "project_${CI_PROJECT_ID}_bot"
    - echo ${BOT_USER}
    - env

policy_manager:
  rules:
    - if: $GITLAB_USER_LOGIN == $BOT_USER
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: never
  trigger:
<snip>

What troubleshooting steps have you already taken? Can you link to any docs or other resources so we know where you have been?

  • Checked the GitLab documentation on pipeline triggers.
  • Reviewed the pipeline logs to see if there’s any indication of the bot user still triggering the pipeline.
  • Searched forums for similar issues but didn’t find a solution that works for my case.
2

Why would the pipeline start automatically again? There needs to be some kind of trigger that starts the subsequent pipeline. What is it?

The reason why it doesn’t work in the rules is variable expansion. Variables in variables: keyword are not expanded, meaning "project_${CI_PROJECT_ID}_bot" is literally 'project_${CI_PROJECT_ID}_bot' when evaluated in rules. So your rule actually looks like this in the end:

- if: $GITLAB_USER_LOGIN == 'project_${CI_PROJECT_ID}_bot'
  when: never

It looks OK in the script, because there it is expanded by Bash.
echo ${BOT_USER} → echo project_${CI_PROJECT_ID}_bot → project_1234_bot

One possible fix is to use:

- if: $GITLAB_USER_LOGIN == "project_${CI_PROJECT_ID}_bot"
  when: never

Or you can update your GitLab instance, variables defined in variables: are expanded in GitLab 15.8.

PS: different major version of GitLab and GitLab Runner is not supported.

1 Like
3

There is a pending upgrade happening soon, I’ll have to find out to what version. We’re missing out on quite a few things, I did not know that variable expansion was one of them. I read that variables are evaluated differently in the variables block than they are in the rules block. I had originally been trying your suggestion, at first in combination with CI_PIPELINE_SOURCE, and then on it’s own.

As to why the pipeline starts automatically again - the pipeline in project A is triggering a downstream project which actually clones project A, does some things, and if it detects changes it will push back to project A as the bot. I believe this push then kicks off the pipeline in project A again. Which I’m trying to prevent. Does that make sense? I could be going about all of this the wrong way.

4

When your downstream/triggered pipeline goes to push back to the upstream/triggering project, add “-o ci.skip” to the git push command. That tells GitLab not to trigger a pipeline on this commit.

You can read more about so-called “push options” in GitLab in the documentation.

1 Like