Centralizing CI/CD Scripts Across Projects

Using Git submodules is a clean way to share CI scripts between projects. You create a separate repository for your shared CI folder and link it as a submodule inside each project.

Steps:

1. Move your shared CI files (scripts, configs, etc.) into a separate Git repo.

2. In each project, add the submodule:

   git submodule add https://gitlab.com/your-group/ci-templates.git CI

3. Commit the changes:
   

   git add .gitmodules CI
   git commit -m "Add CI submodule"

4. Update submodules when cloning:
   

   git submodule update --init --recursive

Benefits:

• Keeps scripts version-controlled and consistent
• Easy to manage changes centrally

Use this when: You want full access to the CI folder and version control it tightly.

GitLab allows you to include .gitlab-ci.yml files from other repositories. This is a powerful way to reuse pipeline templates across projects.

How it works:

include:
  - project: 'your-group/ci-templates'
    ref: 'main'
    file: '/CI/jobs.yml'

Limitations:

• Only works with YAML files (not PowerShell, XML, etc.)
• Files must be structured as valid GitLab CI YAML

Best for: Reusing standard pipeline jobs or templates.

You can fetch scripts during the CI job using curl or wget. This allows you to avoid submodules or includes, especially when you just need to run a script without checking it into your repo.

Example:

variables:
  CI_SCRIPTS_BASE_URL: "https://gitlab.com/your-group/ci-templates/-/raw/main/CI"

before_script:
  - mkdir -p CI
  - curl -sSL -o CI/setup.ps1 "$CI_SCRIPTS_BASE_URL/setup.ps1"
  - curl -sSL -o CI/config.xml "$CI_SCRIPTS_BASE_URL/config.xml"

Advantages:

• Simple and flexible
• Works even if the shared files are in a private repo (with token)

When to use: If you want a lightweight setup without managing submodules.