GitLab Documentation

Triggering jobs through the API


Triggers can be used to force a rebuild of a specific ref (branch or tag) with an API call.

Add a trigger

You can add a new trigger by going to your project's Settings ➔ CI/CD Pipelines ➔ Triggers. The Add trigger button will create a new token which you can then use to trigger a rerun of this particular project's pipeline.

Every new trigger you create, gets assigned a different token which you can then use inside your scripts or .gitlab-ci.yml. You also have a nice overview of the time the triggers were last used.

Triggers page overview

Take ownership

Each created trigger when run will impersonate their associated user including their access to projects and their project permissions.

You can take ownership of existing triggers by clicking Take ownership. From now on the trigger will be run as you.

Legacy triggers

Old triggers, created before 9.0 will be marked as Legacy. Triggers with the legacy label do not have an associated user and only have access to the current project.

Legacy trigger are considered deprecated and will be removed with one of the future versions of GitLab.

Revoke a trigger

You can revoke a trigger any time by going at your project's Settings > Triggers and hitting the Revoke button. The action is irreversible.

Trigger a pipeline

Note: Valid refs are only the branches and tags. If you pass a commit SHA as a ref, it will not trigger a job.

To trigger a job you need to send a POST request to GitLab's API endpoint:

POST /projects/:id/trigger/pipeline

The required parameters are the trigger's token and the Git ref on which the trigger will be performed. Valid refs are the branch and the tag. The :id of a project can be found by querying the API or by visiting the CI/CD Pipelines settings page which provides self-explanatory examples.

When a rerun of a pipeline is triggered, the information is exposed in GitLab's UI under the Jobs page and the jobs are marked as triggered 'by API'.

Marked rebuilds as  on jobs page

You can see which trigger caused the rebuild by visiting the single job page. A part of the trigger's token is exposed in the UI as you can see from the image below.

Marked rebuilds as triggered on a single job page

See the Examples section for more details on how to actually trigger a rebuild.

Trigger a pipeline from webhook

Introduced in GitLab 8.14.

To trigger a job from webhook of another project you need to add the following webhook url for Push and Tag push events:


Pass job variables to a trigger

You can pass any number of arbitrary variables in the trigger API call and they will be available in GitLab CI so that they can be used in your .gitlab-ci.yml file. The parameter is of the form:


This information is also exposed in the UI.

Job variables in UI

See the Examples section below for more details.


Using cURL you can trigger a rebuild with minimal effort, for example:

curl --request POST \
     --form token=TOKEN \
     --form ref=master \

In this case, the project with ID 9 will get rebuilt on master branch.

Alternatively, you can pass the token and ref arguments in the query string:

curl --request POST \

Triggering a pipeline within .gitlab-ci.yml

You can also benefit by using triggers in your .gitlab-ci.yml. Let's say that you have two projects, A and B, and you want to trigger a rebuild on the master branch of project B whenever a tag on project A is created. This is the job you need to add in project's A .gitlab-ci.yml:

  stage: deploy
  - "curl --request POST --form token=TOKEN --form ref=master"
  - tags

Now, whenever a new tag is pushed on project A, the job will run and the build_docs job will be executed, triggering a rebuild of project B. The stage: deploy ensures that this job will run only after all jobs with stage: test complete successfully.

Note: If your project is public, passing the token in plain text is probably not the wisest idea, so you might want to use a secure variable for that purpose.

Making use of trigger variables

Using trigger variables can be proven useful for a variety of reasons.

Consider the following .gitlab-ci.yml where we set three stages and the upload_package job is run only when all jobs from the test and build stages pass. When the UPLOAD_TO_S3 variable is non-zero, make upload is run.

- test
- build
- package

  - make test

  stage: build
  - make build

  stage: package
  - if [ -n "${UPLOAD_TO_S3}" ]; then make upload; fi

You can then trigger a rebuild while you pass the UPLOAD_TO_S3 variable and the script of the upload_package job will run:

curl --request POST \
  --form token=TOKEN \
  --form ref=master \
  --form "variables[UPLOAD_TO_S3]=true" \

Using webhook to trigger job

You can add the following webhook to another project in order to trigger a job:[UPLOAD_TO_S3]=true

Using cron to trigger nightly jobs

Whether you craft a script or just run cURL directly, you can trigger jobs in conjunction with cron. The example below triggers a job on the master branch of project with ID 9 every night at 00:30:

30 0 * * * curl --request POST --form token=TOKEN --form ref=master

Using scheduled triggers

Introduced in GitLab CE 9.1 as experimental.

In order to schedule a trigger, navigate to your project's Settings ➔ CI/CD Pipelines ➔ Triggers and edit an existing trigger token.

Triggers Schedule edit

To set up a scheduled trigger:

  1. Check the Schedule trigger (experimental) checkbox
  2. Enter a cron value for the frequency of the trigger (learn more about cron notation)
  3. Enter the timezone of the cron trigger (see a list of timezones)
  4. Enter the branch or tag that the trigger will target
  5. Hit Save trigger for the changes to take effect

Triggers Schedule create

You can check a next execution date of the scheduled trigger, which is automatically calculated by a server.

Triggers Schedule create