Pipeline triggered by bot without permission to external project cause invalid yaml

I am facing issues with pipelines being triggered when a bot commits to the repository. Using gitlab cloud (gitlab.com).

The pipeline is created manually through the web gui, it modifies some files and commit and push the changes. To push the changes the pipeline job authorize as a bot (access token, created for a specific repository) towards git. The changes are pushed to the repository, but then a new pipeline is triggered by the new commit(s).

Parts of the pipeline is included from another project where the bot does not have read access, because of that the newly triggered pipeline get “invalid yaml”-error.

I have tried to set rules to avoid creating a pipeline on push events, but they have no effect on this issue. I think that the entire pipeline include must resolve before evaluating workflow rules.

Below is a similar scenario (not tested, just theoretical) to my setup, although no rules or worflow rules are used.

  - push
  - hello

  stage: hello
    - echo "Hello world!"
  - project: foobar/pipeline-defaults
    file: hello-world.yml

  stage: push
    - git remote set-url origin "${CI_REPOSITORY_URL}"
    - git config user.name "${GITLAB_USER_NAME}"
    - git config user.email "${GITLAB_USER_EMAIL}"
    - git remote set-url origin "https://${GITLAB_USER_NAME}:${GITLAB_ACCESS_TOKEN}@gitlab.com/foobar/test.git"
    - touch new-file.txt
    - git add new-file.txt
    - git commit -m "Add new file"
    - git push origin HEAD:${CI_DEFAULT_BRANCH}
  • Maybe need some additional things like image etc or install git or other needed libraries/tools

When you now push to the repository a pipeline will be started.
The pipeline will consist of 2 jobs, hello_world and push.
hello_world will only echo “Hello world!” and finish.
push will set up auth to the repository, create a new file (new-file.txt) and push it.

This pipeline will succeed without any issues.
Since the “bot” made a commit in the pipeline above a new pipeline will be triggered by the bot.

The new pipeline is triggered by the bot, therefore the permissions to read files are based on the bot user (only push/pull in https://gitlab.com/foobar/test).
The bot does not have permissions to read from https://gitlab.com/foobar/pipeline-defaults, so the yaml is invalid since it can’t find hello-world.yml.

There might be some extra steps needed in order to trigger this issue, but this should suffice.

Is there a workaround for this issue or plans to fix this?

1 Like

Bots are scoped to the poject or group. There is currently no workaround how to grant access to bot user outside it’s scope.
There are some issues in GitLab issue tracker, but nothing that would be coming soon.

The issue is not that the bot should get more permissions.
The issue is that the pipeline is triggered, the CI is trying to parse all config files.
Since all config files cannot be found/parsed, the workflow rules are not applied (which should block push pipeline triggers and ALSO the bot id).
So instead of not starting the pipeline, the pipeline crashes.

there are couple of options.

If you do not need the pipeline to be started on bot’s commit, add [skip ci] to the commit message. This takes precedence and pipeline will be skipped instead of failed.

If you need the pipeline to be running, you can use Service accounts | GitLab instead.

I want to avoid seeing the pipeline as “skipped”, because that clutters the overview of all the pipeline statuses.
As far as I know, that is only possible with workflow rules, but they will not be applied if including anything from a repository that the bot does not have access to.

I think this is a big flaw.

You can always write workflow rules in the repository’s .gitlab-ci.yml, I agree it’s not super elegant, but it’s a solution.

Since there is an option in the paid tiers to solve exactly the problem you have, I don’t think it will get changed anytime soon for Bot users.

If you are on paid tier, you can share your ideas and opinions with your GitLab representative. If youa re using the Free version, you get what you get.

- if: ‘$CI_PIPELINE_SOURCE == “web” && $CI_PIPELINE_SOURCE != “push” && $GITLAB_USER_ID != “XXXX”’

This is the first thing in my .gitlab-ci.yml file.
But since there are also includes to a repository where the bot does not have access rights, the workflow rules are not evaluated instead I get a invalid yaml error.

Also when I include code from another project

  • project: xxx/gitlab-ci-configurations
    file: scripts/xxx.yml
    • if: $GITLAB_USER_ID != “XXX”

But these rules are not applied either.

It seems that the includes are evaluated before any rules, and because of that I get an error instead of the pipeline not even trigggering.

I will have to test a few more times before confirming, but I think I found a workaround.
I put the include (to other project) into a separate file, and include that file from .gitlab-ci.yml and set a rule - if: $GITLAB_USER_ID != “XXX”.
This seems to give me the desired behavior of not starting pipeline or crashing, since the file that include from the other project is not included by that user.

It did not work as I tested a bit more, it didn’t trigger a new pipeline because there were no new changes to push.