Gitlab Pipeline – default – What is default in GitLab CI/CD?

Here’s a basic GitLab CI/CD YAML (.gitlab-ci.yml) example that demonstrates the use of the default: configuration option, along with an explanation.

The default: keyword in GitLab CI/CD allows you to define a set of parameters that will be inherited by all jobs in your pipeline unless a job explicitly overrides them. This is very useful for reducing repetition and ensuring consistency across your jobs.

YAML

# .gitlab-ci.yml

default:
  image: ruby:3.0 # Default Docker image for all jobs
  tags:
    - docker # Default tags for runners
  interruptible: true # Default for allowing jobs to be cancelled if a newer pipeline starts
  before_script:
    - echo "This runs before every job by default."
    - ruby -v

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "This is the build job."
    - echo "It uses the default image (ruby:3.0) and before_script."
    - bundle install # Example command that might use ruby

test_job_specific_image:
  stage: test
  image: node:18 # This job overrides the default image
  before_script: # This job overrides the default before_script
    - echo "Custom before_script for test_job_specific_image."
    - node -v
  script:
    - echo "This is the test job."
    - echo "It uses a specific image (node:18) and its own before_script."
    - npm install # Example command that might use node

test_job_uses_defaults:
  stage: test
  script:
    - echo "This test job uses all defaults from the 'default:' section."
    - echo "Running some ruby tests..."
    # Example: rspec

deploy_job:
  stage: deploy
  interruptible: false # This job overrides the default interruptible setting
  script:
    - echo "This is the deploy job."
    - echo "It uses the default image and before_script, but is not interruptible."
    # Deployment commands here
Code language: PHP (php)

Explanation:

1. default: Section:
   • This top-level keyword defines default configurations for all jobs in the pipeline.
   • image: ruby:3.0: Specifies that, by default, all jobs will run using the ruby:3.0 Docker image. This means the environment for the job will have Ruby 3.0 available.
   • tags: - docker: By default, jobs will look for GitLab Runners that have the docker tag. Runners use tags to pick up specific jobs.
   • interruptible: true: Sets the default behavior for jobs. If true, the job will be canceled if it’s pending or running when a newer pipeline for the same ref (e.g., branch or MR) starts.
   • before_script:: This block contains commands that will be executed before the script section of every job, unless a job defines its own before_script.
     • echo "This runs before every job by default."
     • ruby -v: This will print the Ruby version, confirming the default image is in use.
2. stages:
   • Defines the order in which jobs will be executed. Here, jobs in the build stage run first, then test, then deploy.
3. build_job:
   • stage: build: Assigns this job to the build stage.
   • script:: Contains the main commands for this job.
   • Behavior: This job does not define its own image, tags, interruptible, or before_script. Therefore, it inherits all of them from the default: section. It will use ruby:3.0, run on a docker tagged runner, be interruptible, and execute the default before_script commands before its own script commands.
4. test_job_specific_image:
   • stage: test: Assigns this job to the test stage.
   • image: node:18: This job overrides the default image. Instead of ruby:3.0, it will use the node:18 Docker image.
   • before_script:: This job also overrides the default before_script. The commands defined here will run instead of the ones in the default: section.
   • Inherited: It will still inherit the tags: [docker] and interruptible: true from the default: section because it doesn’t specify its own tags or interruptible value.
   • script:: Main commands for this job.
5. test_job_uses_defaults:
   • stage: test: Assigns this job to the test stage.
   • Behavior: Similar to build_job, this job does not specify an image, tags, interruptible, or before_script. It will inherit all settings from the default: section.
6. deploy_job:
   • stage: deploy: Assigns this job to the deploy stage.
   • interruptible: false: This job overrides the default interruptible setting. This is common for deployment jobs, as you typically don’t want them to be automatically canceled.
   • Inherited: It will inherit image: ruby:3.0, tags: [docker], and the before_script from the default: section.
   • script:: Main commands for this job.

Benefits of Using default:

• DRY (Don’t Repeat Yourself): Reduces redundancy by defining common configurations in one place.
• Consistency: Ensures that jobs share a common baseline configuration unless explicitly stated otherwise.
• Maintainability: Makes it easier to update common settings (like a base Docker image or a common setup script) as you only need to change it in the default: section.
• Readability: Can make individual job definitions cleaner and more focused on their specific tasks.

When a GitLab Runner processes this .gitlab-ci.yml file, it will first look at the default: section and then apply those settings to each job. If a job has its own definition for a parameter that’s also in default:, the job-specific definition takes precedence.