[dijksterhuis]

> GitHub at least makes splitting massive CI/CD setups easier by allowing you to write them as separate workflows that are separate files.

this makes me feel like you’re really asking “can i split up my gitlab CICD yaml file or does everything need to be in one file”.

if that’s the case:

yes it does eventually all end up in a single pipeline (ignoring child pipelines).

but you can split everything up and then use the `include` statement to pull it all together in one main pipeline file which makes dealing with massive amounts of yaml much easier.

https://docs.gitlab.com/ee/ci/yaml/includes.html

you can also use `include` to pull in a yaml config from another project to add things like SAST on the fly.

previous workplace i had like 4 CICD template repos and constructed all 30 odd actual build repos from those four templates.

used `include` to pull in some yaml template jobs, which i made run when by doing something like (it’s been a while, might get this wrong)

    include:
      project: 'cicd/templates'
      file: 'builds.yml'


    stages:
      - build

    job_a:
      stage: build
      extends: .job_a_from_template
      variables:
        IMAGE_NAME: "myimage"
        IMAGE_REPO: "somerepo.org"

this doesn’t run anything for `job_b_from_template` … you just end up defining the things you want to run for each case, plus any variables you need to provide / override.

you can also override stuff like rules on when it should run if you want to. which is handy.

gitlab CICD can be really modular when you get into it.

if that wasn’t the case: on me.

edit: switched to some yaml instead of text which may or may not be wrong. dunno. i have yet to drink coffee.

[dijksterhuis]

addendum you can also do something like this, which means you don’t have to redefine every job in your main ci file, just define the ones you don’t want to run

    include:
      project: 'cicd/templates'
      file: 'builds.yml'

    variables:
      IMAGE_NAME: something
      IMAGE_REPO: some.org

    job_b:
      rules:
        - when: never

where the template you import has a job_a and job_b definition. both get pulled in, but job_b gets overwritten so it never runs.

less useful when just splitting things into multiple files to make life simpler.

super useful when using the same templates across multiple independent repositories to make everything build in as close to the same way as possible.