Skip to main content
In this lesson, you’ll discover how to streamline your GitLab CI/CD pipelines using reusable templates and various include types. By the end, you’ll be able to eliminate repetitive YAML, enforce consistency across projects, and leverage GitLab’s built-in templates and external includes.

​
The Challenge of Repetitive CI YAML

When you define similar jobs (e.g., unit tests, code coverage) across multiple repositories, you often end up duplicating large blocks of configuration: 
# .gitlab-ci.yml
unit_testing:
  image: node:17-alpine3.14
  services:
    - name: siddharth67/mongo-db:non-prod
  cache:
    policy: pull-push
    key:
      files:
        - package.json
      paths:
        - node_modules
  before_script:
    - npm install
  script:
    - npm test

code_coverage:
  image: node:17-alpine3.14
  services:
    - name: siddharth67/mongo-db:non-prod
  cache:
    policy: pull-push
    key:
      files:
        - package.json
      paths:
        - node_modules
  before_script:
    - npm install
  script:
    - npm run coverage
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual
Maintaining these blocks manually is error-prone and time-consuming. Templates and includes help you define once and reuse everywhere.

​
GitLab CI/CD Templates

GitLab provides two primary template categories:
  • Pipeline Templates
    Full end-to-end CI/CD workflows for common project types (Node.js, Ruby on Rails, etc.).
  • Job Templates
    Standalone jobs for tasks like security scans, linting, or Docker builds.
By including a template, you inherit predefined stages and jobs, then override or extend only what’s unique to your project.
Built-in templates live in the gitlab-org/gitlab repository. You can also publish your own templates in a dedicated project.

​
Example: Reusing a Node.js Pipeline Template

Team A and Team B share a common Node.js template but customize deployment targets:
  • Team A
    • Registry: Docker Hub
    • Deployment: AWS EKS
  • Team B
    • Registry: Google Container Registry
    • Deployment: GKE
Both pipelines run the same stages—unit testing, code coverage, build & push, deploy—but inject different variables, credentials, and script overrides.
The image is a flowchart showing CI/CD pipelines for two projects, "Project A/Repo A" and "Project B/Repo B," both using a "NodeJS Template" for processes like unit testing, code coverage, building/pushing to Docker Hub, and deploying to EKS.

​
Key Takeaways

  • Reusable templates accelerate onboarding and ensure best practices.
  • Modular design lets teams opt into only the stages they require.
  • Customization points (variables, before_script, after_script) handle project-specific needs.

​
Types of Includes

GitLab CI/CD supports four include sources:
Include TypeDescriptionYAML Example
localFiles in the same repo/branch- local: 'jobs/.after-script.yml'
remoteYAML from an external URL- remote: 'https://example.com/ci/.before-script.yml'
projectFiles in another project on the same instance- project: 'my-group/avengers-project'
ref: main
file: '/jobs/.gitlab-ci.yml'
templateGitLab’s built-in CI templates- template: 'Code-Quality.gitlab-ci.yml'
When using local includes, the default branch is HEAD. Specify ref if you need a different branch or tag.

​
Conditional Includes

You can apply includes only under specific conditions using rules: 
include:
  - template: 'Code-Quality.gitlab-ci.yml'
    rules:
      - if: '$CI_COMMIT_BRANCH =~ /^feature\//'
        when: always
This ensures that the Code-Quality template is only included for feature branches.

​
References

Watch Video