Gitlab CI Automation: Nice Things to Know Before Starting - Aircall Blog

Gitlab CI Automation: Nice Things to Know Before Starting

Illustration of a women on the phone in front of a bar chart
Corentin Evanno

At Aircall, we recently migrated from Bitbucket to Gitlab. At the same time, we also decided to get away from Circle CI to run self-hosted Gitlab CI runners managed by our SRE team. This move resulted in the migration of 6 pipelines and 19 jobs for Gitlab CI.

In this post, I will share some advice that I think is nice to have in mind when automating your CI with Gitlab CI. I will not focus on how to get your Gitlab CI running because there is already a lot of nice articles or tutorials showing how to do it. Let’s get started!

Plan what the CI will do

Sometimes the most overlooked step during the setup of a CI, but for me the most important one. A well-planned setup will save you time and frustration. Also, keep in mind that you don’t need to always stick to your plan, changes will happen when getting used to the CI and discovering functionalities.

The first thing when doing the planning is to try to lay out on a piece of paper the pipelines and jobs that you will implement in your CI and how they will be triggered. It will give you a clear overview of what needs to be done so you don’t go in one direction and then back off in the middle of it because you forgot to think about an important thing. Also, don’t skip this if you migrate from an existing CI so you can improve your pipelines!

After doing this first draft see if you can regroup some of the jobs together. In my opinion, it’s better to have one job with a variable parameter versus 3 jobs that have this variation hardcoded.

After all of this is done, you should have a clear overview of what needs to be implemented!

Template your rules

One of the things that started to add a lot of noise during my migration was the list of rules for my jobs. Since a lot of our jobs are reused for different pipelines, rules start to add up and pollute our files. For example, we have a job that runs sonarqube and is used during 5 pipelines.

Discover how switching to Aircall delivered $585K in customer gains
Read the new eBook for free.



Don’t leak your sensitive data

  • Variables/Secrets: Try to put them as masked so they are not displayed when printed in CI logs and put them as protected if you only use them in protected branches or tags. Also, avoid hardcoding them in your .yml.
  • Files: The best way would be to store them on a protected remote service, such as a S3, behind credentials.
  • Artifacts: Your job can output artifacts that are then available for download in the Gitlab UI or with the API. Now let’s say in a job you are retrieving a sensitive file from your S3 and then you make it available for the next job with artifacts. This will make your sensitive file available for download. So always think carefully before passing artifacts.
  • Secret rotation: Think about changing your secrets on a regular basis or when someone leaves the company.
  • CI files: You should not be able to modify them without approval by your team. Always carefully review changes made on them. If you have any doubt ask other people or even better the security team of your company (if you have one).


Tokens and Gitlab account



Push and MR events



a detached pipeline

The phone system for modern business