This post has awakened ancient pagan demons. Only purification by fire can save us now. Please shut down all of your Jenkins machines before it is too late.
Oh dear. Reminds me of when a programmed a batch job processor in Groovy for Jenkins to run a build in parallell. Got it down from 26h to 2h on 14 machines.
I guess that is the point of this divide and conquer example. I did a linear and randomized division to keep it simple ...
Outside of github/gitlab native pipeline runners, my preferred CICD system was Concourse but I've read that Dagger is where it's at now.
Also, newer CICD systems don't offer a webui to configure pipelines but use pipeline descriptors in a declarative file format (YAML usually). Last I used it, Jenkinsfile tried to do the same but I didn't like the groovy DSL _at all_.
I'm building one! It's still under heavy development. Doing a lot of yak-shaving trying to get the internal architecture to suck as little as possible. Jenkins is surprisingly complex. Things that seem like should be simple, turns out is difficult to implement in a way that isn't horrible, when everything is a plugin. The good news is, at the pace i'm going, it should be production-ready in about 2 years :D But at least it will be GPL, and not strangled by some company trying to monetize it.
If you want something today that's closest to Jenkins in design, that would be StackStorm. It's not very trendy, but it has basically everything you need, and a flexible, pluggable architecture. They open-sourced all the Enterprise components too.
Not sure what you mean by "strangled", Jenkins seems quite to open to me, in fact I'm paid to take care of its OSS infrastructure and its community and only that, by the main company behind it, and they don't ask anything more, I feel quite free in my job.
If you want to be radical and meme-y, use a language that compiles fast (ocaml,go for example), nix with local builds for deploys then all you’ll need is commit hooks.
Gitlab and github ci is fine until you're working in an environment with major compliance requirements for self hosted everything and/or basically infinite build history. At that point, sadly you're back in Jenkins world.
Another thing that kills Jenkins alternatives is just a sufficiently diverse number of languages/projects/build types. Plugin ecosystem sucks, but it's massive, and some of it will probably work for whatever use case. It's painful but your only alternative is also painful.. curating custom runner-containers for another ci tool with less existing historical effort to leverage
I didn't know Jenkins was this powerful. Do GitHub Actions and GitLab CI/CD support something similar? I doubt it because they seem to heavily focus on declarative style, though.
41 comments
[ 0.17 ms ] story [ 3787 ms ] threadI appreciate that the author went to the effort of optimizing this given how terribly this would perform in the first place.
Is SVN really that obsolete? I thought it was still used
As one data point, GitHub removed SVN support last year - https://github.blog/2023-01-20-sunsetting-subversion-support...
I guess that is the point of this divide and conquer example. I did a linear and randomized division to keep it simple ...
I don't remember the details it was to long time ago.
Jenkins is... fine, basically, if you can get away with almost never having to touch Groovy.
You, yourself, need to make good choices. Jenkins isn't going to stop you from making poor ones. Reminds me of Jira in that sense.
If you are into dynamic stuff or approvals, you could check out Buildkite.
Also, newer CICD systems don't offer a webui to configure pipelines but use pipeline descriptors in a declarative file format (YAML usually). Last I used it, Jenkinsfile tried to do the same but I didn't like the groovy DSL _at all_.
If you want something today that's closest to Jenkins in design, that would be StackStorm. It's not very trendy, but it has basically everything you need, and a flexible, pluggable architecture. They open-sourced all the Enterprise components too.
Disclosure: this main company is CloudBees
Another thing that kills Jenkins alternatives is just a sufficiently diverse number of languages/projects/build types. Plugin ecosystem sucks, but it's massive, and some of it will probably work for whatever use case. It's painful but your only alternative is also painful.. curating custom runner-containers for another ci tool with less existing historical effort to leverage
1. Implement the Ackermann function.
2. Implement the factorial function using iterative recursion [1]. Does Jenkins execute the function iteratively or recursively?
[1] https://mitp-content-server.mit.edu/books/content/sectbyfn/b...
I think jenkins is very useful yet painful.
Ever since I discovered `act` [1], I made a lot less commits.
[1]: https://github.com/nektos/act