How to detect in GitLab CI that a pipeline was triggered when a Merge Request was created

Question

I'm doing a script that sends a message in Ryver based on certain events for GitLabs Merge Request. The supported scenarios:

1. When a Merge Request is created
2. When comments are made (Code Review)
3. when new commits make the pipeline fail

The following allows to limit the pipeline to merge requests only:

  only:
  - merge_requests
  script:
  - ./ryver.sh #This does the logic of sending the message based on the events

I tried using export to print all the variables in the pipeline but couldn't find a way to explicitly detect the event that triggered this job (Code Review, Creation, etc).

I tried:

• Merge Request status
• Comparing commits
• Using times (not very reliable way)

I wonder:

1. Can we detect what event triggered the pipeline within the Merge Request scope? Or
2. Do I need to use a WebHook to access this information? Or
3. There is another way to do what my team is trying to do?

I'm open to suggestions or other ways to do it that are not related to the gitlab-ci.yml, as long as it is free

Answer 1

Can we detect what event triggered the pipeline within the Merge Request scope?

Yes, this is contained in the predefined CI_PIPELINE_SOURCE variable, as frakman1 answered.

Do I need to use a WebHook to access this information?

It depends what you want to do. as stated above, this information is available inherently in the pipeline as a predefined variable.However, it should be noted that only certain events trigger merge request pipelines at all.

For example, comments on merge requests do not trigger pipelines. If you want to react to comments or status changes, you will probably need a webhook.

The pipeline source information is available both in webhooks and the list pipelines API in the source key of the response (in GitLab 14.3+).
Webhooks expose the event in the X-Gitlab-Event header and payload for the relevant events.

There is another way to do what my team is trying to do?

Webhooks will likely be more reliable than relying on in-pipeline jobs because webhooks can capture more events than jobs/pipelines can. Webhooks, for example, could send you notifications even when no pipeline is created at all. It will also work if your pipeline is blocked/timed out for some reason.

The disadvantage, however, is that you will need to develop and host your own web application to handle the incoming webhooks.

There are many project integrations built into GitLab for sending notification webhooks directly to various services. Unfortunately, Ryver is not one of them.

If you want to send notifications from jobs, I have found using apprise simplifies this greatly and supports ryver.

A basic template job may look like this:

.send_notification:
  image: python:3.9-slim
  before_script:
    - pip install apprise
  variables:
    RYVER_ORG: "YourOrganization"
    # Define RIVER_TOKEN in your CI/CD variables settings
    NOTIFICATION_TITLE: "Placeholder Title"
    NOTIFICATION_BODY: "Placehodler Body"
  script:
    - apprise -vv -t "${NOTIFICATION_TITLE}" -b "${NOTIFICATION_BODY}" "ryver:///${RYVER_ORG}/${RYVER_TOKEN}"

Using jobs in combination with when: on_failure or when: on_success can be useful:

stages:
  - build
  - build_notification

build:
  stage: build
  script:
    - make build

notify_build_failure:
  stage: build_notification
  when: on_failure
  extends: .send_notification
  variables:
    NOTIFICATION_TITLE: "Failed - $CI_PROJECT_NAME pipeline $CI_PIPELINE_ID"
    NOTIFICATION_BODY: "The build failed for the pipeline. See $CI_PIPELINE_URL"


notify_build_success:
  stage: build_notification
  when: on_success # the default
  extends: .send_notification
  variables:
    NOTIFICATION_TITLE: "Build Success - $CI_PROJECT_NAME pipeline $CI_PIPELINE_ID"
    NOTIFICATION_BODY: "The build has succeeded. See $CI_PIPELINE_URL"

Or using a default after_script which will run even if the job fails. This is an easy way to have your ryver.sh script evaluated after each job. The script logic can determine whether to send the notification and the contents of the notification.

default:
  after_script:
    - ./ryver.sh