I’ve become a big fan of Gitlab and especially its Continuous Integration pipelines over recent months as I was setting up the integration test for my current project.
One feature I’ve made use of early on was pipeline triggers – triggering a CI pipeline in another project to fork out the test process. The way this works is by using GitLab’s pipeline API, for example via curl
:
trigger:
stage: trigger
image: appropriate/curl
script:
- curl -X POST -F token=$P_TOKEN -F ref=$TARGET_BRANCH https://gitlab.com/api/v4/projects/$PROJ_ID/trigger/pipeline
There are some parameters to supply:
P_TOKEN
is the access token of the remote pipeline, which is generated when adding a new trigger to a projectTARGET_BRANCH
is the branch you want the remote pipeline to run onPROJ_ID
is the project id of the remote project
but otherwise this is a straightforward HTTP API call. (Note that I’m using appropriate/curl
as a base image here to have access to curl
but you could of course use any other image that comes with curl
.)
However, one problem with that call is that it is a “fire and forget” step in your build process. The request will go through, your pipeline will succeed if the curl
request was successful and do whatever other steps you have set up. But it will not wait for the triggered pipeline to finish nor collect its results.
One way to work around this might be to send a trigger back from the other project along with some variables to route it back to the right stage in the original project’s build process. However, this would get unwieldy quickly with more than a trigger or two, if it works without a convoluted set up at all.
The simpler approach is to trigger the remote pipeline via curl
as above and then poll the remote pipeline via the GitLab API to wait for the job to finish and collect its result. This way the flow stays entirely within the current pipeline and just delegates out one step to the remote pipeline.
Enter Pipeline Trigger. It provides a docker image which is very easy to add as a ready made triggering building block to any GitLab CI pipeline.
For instance, converting the above curl
command to use this image looks as follows:
trigger:
stage: trigger
image: registry.gitlab.com/finestructure/pipeline-trigger
script:
- trigger -a $API_TOKEN -p $P_TOKEN -t $TARGET_BRANCH $PROJ_ID
There are only two differences:
- instead of using curl we use the
pipeline-trigger
base image and its commandtrigger
- we need to create an api token and pass it in to the command
The reason the latter is necessary is because while triggering the remote pipeline is possible without a token, querying its status requires it.
For more details on trigger
view it’s implementation.
The pipeline-trigger
project also comes with its own CI pipeline set up to use the image for testing and looking at its .gitlab-ci.yml
file might be instructive.