When you join a new project, company, customer, etc. (you’re still in the onboarding phase 😅), meanwhile you may find that you need to make a few changes to get your team’s production pipelines up and running. In this case, you can call an API trigger from one project to another (this is just a example).
I’ve been in the situation described above before, and it was how I discovered this amazing feature in GitLab.
Let’s identify our projects:
* Project Caller: This will be the project that calls the trigger API.
* Project Triggering: This is the project where the remote pipeline is located.
From the Triggering Project, you need to activate the triggering token. To do this, go to “CI/CD Settings - Pipeline Trigger Tokens.”
Then, use the generated token and add it as a variable in the “CI/CD Settings” of your Project Caller.
Now, you can activate the trigger from the Project Caller to the Project Triggering. You can use the following example as a pipeline. Please remember, since we’re assuming that we’re working within the production pipeline, you need to add this at the end of the pipeline.
builder_PB_trigger:
before_script:
- apt-get update
- apt-get install -y curl
script:
- 'curl -X POST --fail -F token="$MY_TRIGGER_TOKEN" -F ref="master" --form "variables[STAGE]=testing-abc" https://gitlab.com.company/api/v4/projects/xxxx/trigger/pipeline'
only:
- develop
when: manual
allow_failure: true
On my case my runner needs the curl command, lines explanation below:
* "token" use the name of your variable added.
* "ref" the branch referenced where the pipeline it will run on Project Triggering.
* "variables" on this part the best part it's we can bypass variables from/to. So on this example I'm passing the $STAGE variable to Project Triggering.
* "only" it's a condition I set in order to run this jobs just on "develop" branch, from Project Caller.
* "when" I set this job as manual by design in order to run it just when the developer want it and not consume time it isn't part of the main pipeline.
* "allow_failure" it will be set as true because as we're working into production pipeline so our new lines(job) it wont be interfering with the main pipeline, so we can allow any failure from our job.
Finally we can test the grabbing the variable by a echo ${STAGE} content.