This article is part of Proyek Perangkat Lunak (PPL) or Software Engineering Project Course. Any information written here may or may not be true. Please use it wisely and let me know if there is any wrong information in it.
Have you ever felt the deployment time or waiting for the pipeline in Gitlab CS UI takes forever?
Chill, you are not alone, we felt the same. I know that’s really frustrating when your pipelines take forever but your deadline is around the corner. So how do we overcome those never-ending pipelines?
In this article, I want to share how we overcome that problem. First of all, the reason why our pipelines are slow is that we use the shared runner, but that is not the main problem. The main problem is we pushed to the repository at the same time so that the existing runners are overwhelmed. I know being a deadliner is fun 😂, but it hurts us at the same time.
Look at the picture below
It takes almost 1 hour to run the pipelines, noted that’s only for the test and quality-gates not included the deployment pipeline. If it included the deployment pipeline it may take 1 and a half hours. Also noted that only pipelines for one person imagine if all your team members push at the same time.
VPS to the rescue
Fortunately, our team has a VPS and some GCP. It helps us with the pipeline problem so much. So, the idea is to create our own runner in VPS and GCP and use it on our GitLab repositories. Here’s the step how we implemented it:
- Simply download one of the binaries for your system:
- Give it permission to execute:
- Create a GitLab CI user:
- Install and run as a service:
Ensure you have
$PATH for root or you might get a
command not found error. Alternately, you can install
gitlab-runner in a different location, like
- Register a runner
- Go to the project’s Settings > CI/CD and expand the Runners section.
- Note the URL and token.
- Run the command below
After your runner is up, you can push your code to the repository, and will automatically use your created runner.
You can see your runner in your pipelines terminal, this is the shared runner
If you are successfully created and registered your new runner you may see your new runner’s name, like this
After using your own Gitlab runner, you can see your pipeline is dramatically increased
It takes only 6 minutes to run the pipeline including the deployment pipeline. It’s about 10 times faster than using the shared runner, especially when it comes to deadline time.
As you know, time is money. Time is very important, especially if it’s close to deadline 😂. If you don’t want to face with pipeline’s problem and setting up so many things like this you need to push your code long before the deadline. But if you are true deadliner like me, you need to consider having VPS, GCP, or any other alternative.
Thanks for reading and don’t forget to be grateful!
Due tomorrow, do tomorrow
Install GitLab Runner manually on GNU/Linux | GitLab
If you can't use the deb/rpm repository to install GitLab Runner, or your GNU/Linux OS is not among the supported ones…
The scope of runners | GitLab
Runners are available based on who you want to have access: Shared runners are available to all groups and projects in…
Registering runners | GitLab
Registering a runner is the process that binds the runner with one or more GitLab instances. You can register multiple…