| Jenkins isn't a terrible experience, and I've used it personally and professionally (and would do so again where it's a good fit), but for my current project it missed a few of the requirements. In trying to rationalize the whole NIH thing, I talked to some friends and peers about their CI experiences. I got pretty consistent responses on Jenkins. My relevant requirements: 1.) The software needs to be self-hostable and run on the BSDs. For the most part this narrows down the options to buildbot and the Java based CI options (Jenkins and GoCd). Travis could probably be run on FreeBSD, but the open source bits are essentially abandoned (e.g. some repos are missing) with no documentation. Nearly everything else these days is strongly tied to Linux via docker. Some free hosted services offer a FreeBSD target, but I'm looking to test on DF/Free/Net/OpenBSD. 2.) The software needs to scale down. The GoCd folks suggested that the agent would need around 500 MB of RAM. I haven't profiled Jenkins, but I can't imagine the agent being that much lighter weight. Certainly the Jenkins server process is glacially slow. By contrast my prototype in Rust is showing memory usage of under 5 MB for each process (agent + server). I expect that to grow a little but, but not by an order of magnitude. 3.) The software needs to handle multi-arch builds. Travis does this extremely well. Buildbot and GoCd, kinda. Jenkins does not handle this use case (e.g. pipelines + matrix builds are not supported). I really like the way Travis basically handles these as sub jobs. My experience: A.) The Jenkins documentation is terrible, if it exists at all. I've heard that this has been improved in the year or so since I've looked at Jenkins (but that hasn't been my experience). I mentioned this to one of the CloudBees guys at the DevOps Days conf I went to last year and got an ack that this is a known issue (although CloudBees has driven a ton of Jenkins documentation and improvement). At MegaCorp we paid a fortune to CloudBees, which helped a ton but didn't really help end users. I cannot understate just how much of a detriment the documentation is. At the opposite end of the spectrum rust (except for the async stuff) and postgres are just a dream come true. If it's any consolation the GoCd documentation is pretty atrocious as well. Almost none of it is up to date with the current UI. B.) The Jenkins community tends to cargo cult Jenkins-Groovy snippets like crazy, potentially as a result of #A. Having a good community helps documentation and helps when there are gaps in the documentation. C.) Bootstrapping Jenkins is not something easily done in an automated way. The CLI is not stable and I had tons of trouble trying to get plugins and dependencies sorted without having to drop into the GUI. For homelab stuff I've automated bootstrapping of nearly everything except for Jenkins with Ansible. I don't think these are new or unknown issues as in talking to friends and peers I've found that the typical responses regarding Jenkins are along the lines of: Jenkins works well enough so that we're not motivated to switch, but A & C are our main pain points. |
On C, I think we've made a good progress <https://github.com/jenkinsci/configuration-as-code-plugin> that I think you'd like.