future idea: create pipeline yaml loally and commit
Why ?
Creating pipelines locally and check it in opens a lot of potential:
- you can use packages in your catladder.ts file, that can be used for a plugin-sytem. (you currently CAN use custom code there, but not packages, since
yarn install
is not executed to create the pipeline (in order to speed things up) - we can support other ci/cd runtimes as github actions and azure devops without worring how to create pipelines on-the fly
- it makes the pipeline more predictable, since it will run the exact version that you commited
- there won't be a child-pipeline anymore which simplifies the ui in gitlab
- you could "eject" from catladder by just using the (humongous) created gitlab-ci-file ;-)
- we can generate other resources as well locally
- makes it easier to review how changes in catladder (new version or changes in the catladder-config) affects your project
Context
Its not possible to use a generated .gitlab-ci.yaml file, so we create a child-pipeline instead that can consume a generated pipeline-yaml file.
however looking forward, it would be nice to support other devops tools like github or azure where i am unsure if a similar approach would also work.
Therefore an idea would be to create the .gitlab-ci.yaml (or other job definitions) locally. We could leverage direnv to watch catladder.ts config and whenever a change is done, we update the .gitlab-ci.yaml
that would also make the pipeline more predictable (And version locked) and its easier to review the consequences of changes in catladder.ts (but introduces bit of noise)
There are some preparations that would need to be done:
- the generated pipeline currently only contains jobs for a given "trigger" which is either main, mr or release. A generated one would require all jobs and instead use Rules to define which jobs to run on mrs, tags and branches
- there are certain env-vars (like commit-infos and crrent mr id) that are used by catladder to generate the pipeline. E.g. those are used to define the additional review-slug. This is actually a bit quirky as you might notice when generating the pipeline locally. The solution would be to not directly rely on those variable and instead define variables in the pipeline that reference those variables. Branching logic is a bit awkward with that, but should be doable. I think the only relevant case is the difference between a MR and main-branch or release-tag: on reviews, there is an additional suffix to the release name (pan-myapp-review-mr523) and environment
- it would be good to control the envrc files as well (maybe generate them)