GitLab Auto Devops provides a powerful set of features out-of-the-box that works with no CI configuration at all. It’s useful for demos, or for learning about best practices for GitLab CI. But most customers need to modify the devops pipeline to suit there needs. Fortunately, we don’t have to start from scratch. We can include Auto Devops and override it.

How to override

To override Auto Devops, make sure that:

  • There is a Kubernetes cluster configured (if you plan to use the Review Apps or deployment features); and
  • The repo contains a Dockerfile, a .buildpacks file, or is of a type recognized by Heroku buildpacks (if you plan to use the build and test features); and
  • There is a .gitlab-ci.yml file at the root of the project with an include: statement

The simplest version of including Auto Devops is:

  - template: Auto-DevOps.gitlab-ci.yml

… which will include all of Auto Devops, just as if the Auto Devops checkbox were checked for the project! Of course, that’s not so useful. But now we can start to make changes.

Always skips the scans

Now it’s easy to build in skips for all the scans, as a way of speeding up the build process while working on the CI configuration (or if they just aren’t useful to you).


Run tests earlier

The Auto Devops test job, which uses Herokuish for testing, does not rely on the Docker image that’s generated during the Build job (technically, some if not all of the other scans also do not rely on the container). So try moving the Test job to the Build stage to speed things along!

  stage: build

Run a different test job

Or, if Herokuish doesn’t run the right tests, just run your own.

    - echo "Alternate test script goes here"


Literally any part of Auto Devops can be overridden in your own CI configuration. Doing so allows for an easy medium between the full use of Auto Devops and creating your own CI configuration from scratch.