If you don't put it centrally then where would you put it? Is there more than one submodule to run CI against? Do you want to publish some kind of docker container from this CI job?

in gitlab's CI you can include files and bring flows from them into your gitlab-ci.yml , vs. just write everything in your own ci file

So include a file from different repository? Then what if you build a container and you can't reproduce that container again?

that's certainly an issue But other questions, such as where do you want your definitions of different CI stages, including tests, coverage reports and more also bother me Because when you include a CI file from another repository, you can take the latest (default), tag, or commit. So you either get updates by surprise or suffer from bitrot and never update

What about deployment? Would you be happy if deployment would also fail midway?

I'm not happy about this at all

here's the reference documentation btw

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

If you're happy about it you can include from a branch. Then you'd be having release tags (at least in theory you should be able to use tags if you can use branches) which you could probably be able to use in these includes in a safer way. At least a tag won't change. But then it defeats the purpse -- you wanted the buildscript to update automatically and you didn't want to specify the version (you wanted the build to not be reproducible but you wanted it to be reproducible).

I didn't say I'm against specifying versions. But I see the tradeoffs

I don't like any option here,tbh

I'm just stating your problem back to you. Sometimes it helps if someone does it 😄

I tried to use. It was the worst experience of my life 😄

See this, specially the part about the CI (even if you don't agree with the post): https://mauricio.szabo.link/blog/2021/07/13/the-end-of-an-era-goodbye-github/ TL;DR; (not really too long) - could not debug when things didn't work, could not run docker locally. Found lots of bugs, some open 2 months ago, some open for 11 months ago; could not propagate caches to my local workers, and could not run xvfb - gave up and sent everything to CircleCI

Well, this is about gitlab not github, but there's some overlap with the structural pain points. Wish I could run CI with babashka

Or even Nix

At our company (we have over 100 clojure repos) basic checks (e.g. linter) are run on PRs - but the main build of all repos is kicked on in a central build repo once code is committed to any other repo. This ensures that any change is compatible with all code in all repos - not just the repo that was changed. Devs are also able to run all tests (across the subset of repos they have access to) locally so they don't have to rely on the build server to do this for them. This is using Github rather than Gitlab. The pros for us is that we get the benefits of multi-repo access control and modularity with the benefits of consistency that come from mono repo build/testing.

> Wish I could run CI with babashka Or even Nix It's probably possible to shell out to babashka or a docker command running nix and putting all of your logic in there. For us our CI pipeline is a single step - that contains all the logic in a bash script. Makes things more portable between CI providers + local development.

@UK0810AQ2 yes, I know - my post explains a little bit on how I tried to use GitLab's CI and it failed miserably, and the other option that I like (CircleCI) didn't have support for Gitlab at the time (currently it does. Sure, it's not perfect, and I feel CircleCI's quality degraded over time, but at least now it works)

I'd be interested in seeing something that can decouple CI from collaboration completely. One interesting solution I saw was a https://radicle.xyz/ , and with a bit of proof of work, CI could be run on any machine for any commit. Then there's no need for any central forge or CI provider. Ensuring the CI is reproducible would require something like Nix, probably