[lomnakkus]

I find that it's just like the bug tracker space: There's a lot of contenders, but somehow none of them actually hits the sweet spot.

For CI, it's either: "too GUI" or "not enough programmable".

Also, CI is an area that absolutely cries out for container technology, but the state of containers on Linux[1] is absolutely abysmal. Maybe it'll be better in ~5 years when we'll hopefully be about 40% towards the capabilities with Solaris Zones. (Here's a hint: If you cannot fully 'contain' root and users/mounts/devices, then you're not being serious.)

[1] The most popular platform for this, by a far margin.

[dasmoth]

I think an aspect of the problem is that most tools in this space actually get sold to project managers (and secondarily, process-oriented senior engineers), not hackers who just want to shut the door, quit Slack, and build stuff.

I think it's interesting to consider what hacker-oriented tools might look like. GitHub close to launch might qualify: simple interface, a model where (at least conceptually) projects are owned by individuals not organisations, and a simple but pretty pleasant-to-use issue tracker with no "workflow" type mechanisms. A lot of this has changed now (support for mandating code reviews!) and from a revenue point of view I'm not sure they're wrong to do these things. But it was the simple, hacker-friendly version that got them their initial mindshare.

I'm not entirely sure what the GitHub 1.0 of CI would look like, but probably not like the current offerings.

[a-saleh]

Which camp of "too GUI" or "not enough programmable" does jenkins fall in?

How would the sweet-spot look like?

[lomnakkus]

"not enough programmable", but I'll add the caveat that I haven't really caught up with the 2.x bits that I think could help quite a bit.

(However, from the documentation I got the impression that the new 2.x Jenkins bits were quite repository-centric. It turns out that what I want is really to define the whole CI infrastructure separately from my repos with a few rules to generate appropriate jobs, etc. Perhaps the solution to that is to just define a repo for all-the-builds? Still need to look into it.)

[a-saleh]

I think currently you are supposed to use the "Multi-branch pipeline" for that, where you have separate branch in your repo for every configuration/job you would need.

We have decided to go different route, even though it is kinda held together by duct-tape :)

1. We have several shell-scripts that use the $JENKINS_URL/script to update global configuration. A.f.a.i.k. the /script endpoint gives you access to almost all of the jenkins internals to be operated with groovy. So thats how we set-up i.e. plugins, slave-providers, secrets, shared config-files, e.t.c

2. for job definitions, we use jenkins-job-builder [1] with the pipeline plugin [2] We then store both the job-builder configs and the jenkins-files they point to in a single repo, achieving the "define a repo for all-the-builds" solution.

3. to reduce repetition we used shared pipeline library, where we put all of (groovy) functions to be shared across jobs.

Neither shell-scripts for /script endpoint or the job-builder configs are particularly nice, but they get the job done. But we used them even before jenkins-files/pipelines/2.x

The 2.x bits do help quite a lot :-)

[1] https://docs.openstack.org/infra/jenkins-job-builder/ [2] https://github.com/rusty-dev/jenkins-job-builder-pipeline

[lomnakkus]

Is multi-branch pipeline really flexible enough to handle e.g Haskell/Cabal projects and Scala/sbt projects and "random things that I'll be happy to specify in a bash script?"?

Remember, I need this thing to be invoked by Gerrit, periodically, whenever there's a push (well, polling would be fine on this one), etc.

It turns out this is pretty complicated... and maybe nobody does it just right for you. (Hence my other comment. I want ultimate programability. As long as you give me visualization, then I'm OK. I can deal with having to edit a file and pushing rather than doing it through a GUI.)

[vorg]

Would be nice if we script those Jenkins pipelines with some other languages besides Apache Groovy. And why are Groovy's functional methods inhibited when used within Jenkins?

[a-saleh]

The reason why you can't use functional methods of Groovy in jenkins is, that the intepreter that runs inside of jenkins has been rebuild so that jenkins can suspend/resume the execution of the pipeline.

This means that everything needs to be serializable, and that in reality you are not really executing groovy statements, but rather passing continuations.

This is a reason why you have @NonCPS annotiation, that allows you to opt-out of that behavior.

[lomnakkus]

FWIW at this point, this kind of demonstrates my point: I think I kind of want a library to build a CI system. Not some piece of software I have to run somewhere (as root, probably), which may enable me do to what I want.

Why hasn't anyone developed a CI-orcherstration library yet? Is it actually a difficult problem?