GitLab - include keyword

Some time ago GitLab has introduced include keyword that:

allows the inclusion of external YAML files.

Everyone knows that microservices like to multiply. Thus, this feature is very useful when you have microservices, because you do not have to copy & paste the code. Let's see what can you do with this.

Let's assume that we use Docker and we need to build an image. If you want to build an image and deploy your microservice you can just make a new .gitlab-ci.yml file in your project and add two jobs: build and deploy:

When you have three/four microservices you can tempt to copy & paste this code to the rest of the projects. But, if you have more projects and you need to change the logic of deployments, then you have a problem, because you need to edit many .gitlab-ci.yml files. You do not want to do that, so how to deal with it?

Use include keyword!

It is very simple. For me in most cases creating one gitlab template file is enough. Let's call it gitlab-template.yml. We need to store it somewhere. It does not have to be GitLab itself. You can store the file wherever you want. But I encourage you to use gitlab repo. You will have less problems. Let's create a repository where we are going to keep this file. Other microservices will include this file. Let's call the repo: ci-template and put gitlab-template.yml file on master branch. The content of this file is exactly as the above one.

Now, we want to include this file in our microservices repositories. We know the name of the repository, the name of the file, and the name of the branch, thus we can set up .gitlab-ci.yml file in our microservice:

In this way, when you create a new pipeline, your microservice project will merge the content of the file from ci-template project to .gitlab-ci.yml file.

Let's say that you want to add another step to your pipeline: tests. But, we do not have tests in all projects yet and a command for tests is not always the same. Can we still use include keyword? Of course!

We can add another section to gitlab-template.yml (the test section) file:

We pull an image and run linter in the before_script section. Additionally, in the script section, by default we just print information that you have not added any tests yet. If you want to add tests to your project you should overwrite the script section. How to do that? Remember that you can overwrite every job in your .gitlab-ci.yml file (which are "inherited" from gitlab-template.yml file). So, you can edit the script section:

Yeah, everything will be the same, you just changed the script section, nothing else. The job will pull an image, run linter (the before_script section) and run your tests without printing info that you have not added any tests because you overwrote the script section.

And that's it.

Video bonus:



Location: Wrocław, Poland

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

GitLab - trigger keyword

Image
 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: multi-project pipelines child 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-
Read more