GitLab CI – First experience

I tried GitLab CI for the first time today. I absolutely love GitLab, it’s a wonderful product and gets better and better each week. That’s the reason I wanted to try out GitLab CI. GitLab CI is a Continuous Integration platform, providing a compact solution for deploying your code via pipelines.

I’ve been using Jenkins 1.x for a while, but I got really tired of having to manually create and config each job. GitLab CI automatically detects push to branches that contain a .gitlab-ci.yml file and automatically executes the script, so you can control the entire CI process in a single version-controlled file, which is awesome! This is possible because GitLab manages all your repositories so it always knows when you push code.

What I like about GitLab CI:

  • Pipelines
  • .gitlab-ci.yml in YAML and version-controlled
  • Automatic discovery of branches that contain a .gitlab-ci.yml
  • Automatic discovery of repositories (because GitLab manages them)
  • Docker support
  • Distributed cross-platform runners
  • Tagged runners (e.g. Windows, Linux)
  • Manually run jobs/stages

But it also has some disadvantages:

Pipeline UI is too simple

Simple is good but too simple is not. I think the pipeline view could be improved and made more condensed.

Pipeline progress doesn’t update asynchronously in UI

This is major because you shouldn’t have to refresh the page to see if the build succeeded or failed. Come on, this is crucial.

Slack notifications on build/pipeline events are not informative enough

We use Slack a lot and like to keep track of progress and status of builds in our channel. The Slack notifications look the same for the pipeline and build events and do not display information like the stage or job names. It only displays the project name, commit hash and status, so you have to click on it to get more information. I think it could be improved.

Leave a Reply

Your email address will not be published. Required fields are marked *