GitLab - trigger keyword

 We are going to talk about the trigger keyword today. With this feature you can define a downstream pipeline trigger. So, you can trigger a pipeline in any project (you must have access to this project of course). There are two types of downstream pipelines:

 Let's omit child pipelines and have a look at multi-project pipelines. It is very easy to use. You just need to provide a path to the project and that's it. Remember that you only can trigger a pipeline, not a job! You can also provide more information like environment variables.

As always, I am going to provide some examples, so you will understand it better.

The first example: you want to trigger a pipeline in another project after the deployment of your service/s. How to do that? Here we want to trigger this pipeline (project my/run-tests). Let's say that we want to run some tests after each deployment:

We need to add the job which will trigger this pipeline in my/run-tests project. So, we have to add a job in our service and this job will trigger a pipeline on let's say master branch. Here is the example:

You can see that the job which triggers a pipeline does not have a script section and it is okay. It also does not have after_script or before_script sections, because it would make no sense. The purpose of this job is to just trigger a pipeline, nothing else. Okay, so what will happen then? When the trigger job starts, it will trigger a pipeline in your project my/run-tests (where we have two jobs: linter and test). And that's it. The last job will just trigger a pipeline in another project.

It is important that by default, the trigger job completes with the success status as soon as the downstream pipeline is created. In most cases it is fine, but sometimes you want to depend on the triggered pipeline. We will touch this topic later.

Let's say that we have many microservices and we want to be able to deploy all of them (from a specific branch) in the same time. We only want to deploy them, but there are many other jobs in their pipelines like linters, tests, building an image, etc. Can we just trigger a specific job? No, we can only trigger a pipeline, but! With some Yaml and GitLab magic, we can create a pipeline with only a specific job!

Firstly, let's look at the pipeline of a microservice:

There are only three jobs: build an image, run tests and deploy the image. If you did not change anything, the trigger job would run the whole pipeline. But, we just want to spawn a deploy job, nothing else. How can we do that? We can use the rules keyword and disable some jobs only when a pipeline is triggered:

This way, when a pipeline is triggered, you will see only the deploy job in the pipeline. You will find more info about $CI_PIPELINE_SOURCE environment variable here. And, here is the example of the job which triggers a pipeline in a microservice:

Have you spotted the strategy keyword? Great! According to the GitLab documentation: 

To force the trigger job to wait for the downstream (multi-project or child) pipeline to complete, use strategy: depend. This setting makes the trigger job wait with a “running” status until the triggered pipeline completes. At that point, the trigger job completes and displays the same status as the downstream job.

So, in your case it will tell us the truth about the deployment status! Here is the output of this pipeline:

As you can see our job in project A triggered a pipeline in project B, and additionally, because we changed properly the logic of the pipeline of the project B, the pipeline spawned only the deploy job.

I made these repositories public and you can find deploy-microservices project here and microservice-a project here. You can look at .gitlab-ci.yml files there. Have fun!

I have also created a video about this keyword:



Comments

Post a Comment

Popular posts from this blog

GitLab - extends keyword

Image
In the previous post I had written about the include keyword. Now, let's dive in the extends  keyword. What can you do with this? Here is the definition from GitLab documentation: extends defines entry names that a job that uses extends inherits from. It’s an alternative to using YAML anchors and is a little more flexible and readable. So, when is it useful? It is useful when you want to be DRY and keep your setup cleanly. Let's assume that you want to build a docker image and give developers possibility to deploy the image on dev , staging and prod environments. We are going to do that without the extends keyword, and after that we will think how we can do it better. Example without the extends  keyword: As you can see, there is a lot of code which repeats itself: stage, image, when  and script . We can remove a lot of code! So, let's do that. We are going to create a hidden job .deploy  (you will not see this job in a pipeline) and the rest of the jobs will in
Read more

Managing Secrets in GitLab / Git

Image
Let's say that you have to log in via ssh into an instance, and you work with GitLab, so you want to keep the private key in GitLab somewhere. Is it secure? Let's see! Custom environment variables You can use custom environment variables. Here you can read more about them (Developers cannot change them, only Maintainers and Owners can). There are two types of variables: Variable (the runner creates an environment variable that uses the key for the name and the value for the value) File (the runner creates an environment variable that uses the key for the name. For the value, the runner writes the variable value to a temporary file and uses this path) It seems that we can use File type for our purpose. We can set up it via API or UI . So, let's do that! Go to project's Settings > CI/CD . There will be Variables section (btw, you can specify variables also per group and even for all projects (in admin panel)). Click Add Variable button and add a variable: Key:
Read more