Why I use and prefer GitLab CI

In the past, I talked about how to make your CI builds faster using Drone CI. I don't use DroneCI any more and haven't for a couple years now so I wanted to talk about what I use now.

Now, I use GitLab CI for my CI/CD integrations and builds. By this, I mean client and personal projects. Projects I continue to use GitHub and TravisCI for include:

• Esqueleto
• Bloodhound

I prefer GitLab CI for my projects because:

• It's Docker based like Drone CI. You push an image, that's your build environment.

• It doesn't have an API that barfs on ostensibly valid JSON like Drone CI.

• If you run your own GitLab instance, you can access the Docker host and use it to build and push images.

• GitLab themselves offer free CI on the public site in addition to free private repositories.

• GitLab and GitLab CI are open source. If I run into a blocker, I can fix it if I need to.

• Running GitLab CI yourself doesn't require talking to a sales person and you won't end up on an excessively old version of GitLab unless you want to. GitHub Enterprise carries these concerns for us.

• If the only reason you'd want to run a GitLab instance is so you can use your own runners, then you don't need to run your own GitLab instance! You can setup runners for use on the public GitLab.com instance yourself. I use my desktop for this on some projects to make the builds run faster.

• The YAML specifications for the jobs are familiar and comfortable if you're coming from a TravisCI-style background. Your build specifications are part of your Git repository.

• You can associate a build with a test environment deployed expressly for that branch. GitLab CI supports this natively.

• GitLab's issues and repo structure have been fine, so I don't mind using them for those purposes with the CI since it means the integration is more seamless.

The only real negative I've run into with GitLab CI is that integrating it with a repo that lives on GitHub has been a pain in the past. I liked using the CI enough that I migrated the repository rather than try to debug GitHub's hooks.

GitLab CI is the default for the infrastructure we deploy for our clients at FP Complete, which is how I came to be exposed to it. We will sometimes use Azure Pipelines when we need Windows or macOS support. I hope this post helps if you're making decisions about what CI you use!

Oh, and this blog post was pushed to my static website automatically by GitLab CI.

Here's an example CI/CD deployment configuration for a website I maintain:

stages:
    - build
    - deploy

image: registry.gitlab.com/org/site:latest

staging-deploy:
    stage: deploy
    environment:
        name: staging/$CI_COMMIT_REF_NAME
        url: https://staging.site.com/$CI_COMMIT_REF_NAME/
        on_stop: stop_staging
    script:
        - make deploy-staging
    only:
        - branches@org/site
    except:
        - master@org/site

stop_staging:
    stage: deploy
    environment:
        name: staging/$CI_COMMIT_REF_NAME
        action: stop
    script:
        - make remove-staging
    when: manual

site-deploy:
    stage: deploy
    environment:
        name: site
        url: https://site.com/
    script:
        - make deploy
    only:
        - master@org/site

The only changes were a search and replace of $SITE and $ORG. The actual scripts or commands executed live in the Makefile.