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/pipelineThere are some parameters to supply:
P_TOKENis the access token of the remote pipeline, which is generated when adding a new trigger to a projectTARGET_BRANCHis the branch you want the remote pipeline to run onPROJ_IDis 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_IDThere are only two differences:
- instead of using curl we use the
pipeline-triggerbase 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.
