[bramblerose]

In the end, this is the age old "I built by thing on top of a 3rd party platform, it doesn't quite match my use case (anymore) and now I'm stuck".

Would GitLab have been better? Maybe. But chances are that there is another edge case that is not handled well there. You're in a PaaS world, don't expect the platform to adjust to your workflow; adjust your workflow to the platform.

You could of course choose to "step down" (PaaS to IaaS) by just having a "ci" script in your repo that is called by GA/other CI tooling. That gives you immense flexibility but also you lose specific features (e.g. pipeline display).

[thayne]

The problem is that your "ci" script often needs some information from the host system, like what is the target git commit? Is this triggered by a pull request, or a push to a branch? Is it triggered by a release? And if so, what is the version of the release?

IME, much of the complexity in using Github Actions (or Gitlab CI, or Travis) is around communicating that information to scripts or build tools.

That and running different tasks in parallel, and making sure everything you want passes.

[perlgeek]

> Would GitLab have been better?

My impression of gitlab CI is that it's also not built for monorepos.

(I'm a casual gitlab CI user).

[dezgeg]

I'm not sure if there's a monorepo vs polyrepo difference; just that anything complex is pretty painful in gitlab. YAML "programming" just doesn't scale.

[Hamuko]

Doesn't everything in GitLab go into a single pipeline? GitHub at least makes splitting massive CI/CD setups easier by allowing you to write them as separate workflows that are separate files.

[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.

[dezgeg]

You can have pipelines trigger child pipelines in gitlab, but usability of them is pretty bad, viewing logs/results of those always needs extra clicking.