GitLab CI

Photo by Markus Spiske on Unsplash

In this article, we will see what a basic Gitlab CI looks like and also how we can enable multi-project pipelines and parent-child pipelines.

Main components of Gitlab CI:

.gitlab-ci.yml: This file is placed in the root of your GitLab repository used to define the CI/CD process. It defines the jobs, scripts, and rules for running your pipeline.

Runners: Runners are agents responsible for running the jobs defined in the .gitlab-ci.yml file. They can be shared or specific to a project.

Job: Set of instructions that is set for execution at different stages of your CI/CD process.

Stage: Visualize this as different phases in your CI/CD like Build, Development Deploy, Testing, etc. Inside each stage, the jobs could be made to run in parallel or one after the other.

Environment: Environments in GitLab CI represent different deployment targets, such as development, staging, or production

Trigger: This helps you to trigger the pipelines from another project.

Variables: Variables are used to store sensitive/insensitive data and use it in the pipeline.

Let us see what a root structure may look like.

GitHub - sunilharipkd/sample-gitlab: gitlab-ci references

In the above sample GitHub project, .gitlab-ci.yml has different stages that show how to define the stages to execute locally, to trigger child pipelines, and also multi-project pipelines.

Sample references:

https://docs.gitlab.com/ee/ci/yaml/index.html — syntax reference

https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html — downstream pipeline references

Tip to reduce code duplicity

Photo by Pablo Arroyo on Unsplash

If we have a set of code repeating for specific stages for multiple jobs, for ex: the rules section for a specific stage is repeating for all the jobs, this could be avoided by defining the rules section once and used across the yml file.

#section that gets repeated across all stages  
rules:
    - if: '$CI_COMMIT_TAG || $CI_MERGE_REQUEST'
      when: never
    - if: '$CI_COMMIT_BRANCH == "main"'
    - if: $CI_COMMIT_BRANCH =~ /^feat.*/
      when: manual

You can use YAML anchors and aliases. This way you can reuse the components and reference them in multiple places.

.common_build_stage_rules: &common_build_stage_rules
  rules:
    - if: '$CI_COMMIT_TAG || $CI_MERGE_REQUEST'
      when: never
    - if: '$CI_COMMIT_BRANCH == "main"'
    - if: $CI_COMMIT_BRANCH =~ /^feat.*/
      when: manual

echo-project:
  <<: *common_build_stage_rules
  stage: build
  image: docker:20.10.16
  script:
    - echo "this is testing for build"

test-project:
  <<: *common_build_stage_rules
  stage: build
  image: docker:20.10.16
  script:
    - echo "this is testing for build"

validate-project:
  <<: *common_build_stage_rules
  stage: build
  image: docker:20.10.16
  script:
    - echo "this is testing for build"

Incorporating triggers, rules, anchors, and aliases in your .gitlab-ci.yml file can significantly enhance the flexibility, readability, and maintainability of your CI/CD process.

In the context of an enterprise’s DevSecOps transformation journey, the support for child pipelines and multi-project pipelines in GitLab CI presents a wealth of opportunities, offering developers a fresh perspective on CI/CD practices.

“Everyone can code”

Thanks for reading.