What do the values for gitlab's predefiner variable CI_PIPELINE_SOURCE mean?

Viewed 6061

In the gitlab documentation you find a list of predefined variables HERE, where the variable CI_PIPELINE_SOURCE is explained to have the possible values "push, web, schedule, api, external, chat, webide, merge_request_event, external_pull_request_event, parent_pipeline, trigger, or pipeline."

However, it is not explained, what they mean.

  • push: When you push something to a branch?
  • web: When you trigger a pipeline from the web GUI?
  • schedule: When a pipeline is triggered by a schedule
  • api: When the pipeline is triggered by an API request
  • external: ???
  • chat: ???
  • webide: ???
  • merge_request_event: Seems to be triggered when a merge request is created. Does not trigger when a change is actually merged
  • external_pull_request_event: ???
  • parent_pipeline: ???
  • trigger: ???
  • pipeline: another pipeline?

If someone knows where the documentation for that is hiding, I appreciate if you can let me know where to find it.

In addition, how can I figure out when some changes are actually merged into a branch? How can I trigger a pipeline in that event?

1 Answers

Regarding your first set of questions, i have to point you forward to the gitlab CI Documentation and the rules:if section. They have their a good explanation of the states and also some addtion https://docs.gitlab.com/ee/ci/jobs/job_control.html#common-if-clauses-for-rules - i am just screenshoting this, so people can relate to it in the future if the link gets outdated:

CI_PIPELINE_SOURCE

Regarding your additional question:

A merge is a push. We do not check on some branches for CI_PIPELINE_SOURCE but for the branch name and do checks simply against that like:

    rules:
        - if: '$CI_COMMIT_BRANCH == "master"'
        - if: '$CI_COMMIT_BRANCH == "develop"'
        - if: '$CI_COMMIT_BRANCH =~ /^release.*$/i'
        - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

This works eg perfectly in our case for gitflow. But you can vary your rules and easily define them to your own needs - the rules documentation gives a lot of good examples see: https://docs.gitlab.com/ee/ci/jobs/job_control.html#common-if-clauses-for-rules

Related