I meant to not starting with the issues of CI but the complexity of it and how many solve it. There is the simple shell script idea which mostly runs on this on

I meant to not starting with the issues of CI but the complexity of it and how many solve it. There is the simple shell script idea which mostly runs on this one CI system and nowhere else. Or the we use a build system which abstracts all kinds of things away but need a good chunk of knowledge to understand why it’s there in the first place. Developers from camp shellscript with the desire to keep it easy ask: „why do this etc etc“. It’s not that their wrong it’s mainly the ignorance of other things like build reproducible builds and platform and system tools abstractions that make these more complex. To just expect that some developer who never dealed with a multi arch/platform product to just willingly jump into the complexity is unfair. I also don’t like the current CI landscape. I still run a Jenkins at work cause it gives me the most freedom and I know it best (it’s sadly what keeps me off other systems, at least I know what parts not to touch). We use gradle which I really liked 5 years ago. We also use it for other non Java systems since it is pretty adoptable. But the recent version changes bring more and more weird changes which make it harder and harder to maintain custom plugins for it. The rules to code build plugins are more stricter enforced by the compiler which yes is good for gradle but hard to maintain as one needs to read up and understand why one can no longer access a file input outsite of a build execution phase for example even though it worked fine for the last 4 versions. And then there is more.