Who still uses Jenkins? It's an abomination of an obsolete system that is just a pain to use, manage, maintain, setup, etc. while there are much better, more featured, easier to use and maintain alternatives out there. And it has been like this for close to ten years now. It should have been ripped out in favour of either the "native" CI/CD (e.g. GitLab CI if GitLab is used for VCS, GitHub Actions if GitHub, etc.) or a modern one like Drone/Concoure/etc. years ago in any place that isn't ~two decades behind (so legacy airlines and banks?).
Switched from a company using Jenkins to one using GitLab CI, and while GitLab CI is obviously "better" in the sense that it has less historical baggage, there are actually quite a few things I'm missing. Jenkins has a plugin for pretty much every obscure thing you can imagine, which is a blessing for the user and a curse for the administrator, as Jenkins quickly becomes Frankenstein's monster. But every time I have to wade through tons of log ouput on GitLab I miss Jenkins' warnings plugin, every time no runner is picking up my job I miss the nice runner overview of Jenkins which quickly showed you what runners are actually busy with, and every time that old slow runner is grabbing all the jobs I miss the runner prioritization... I could go on here, but really, there's a lot of things that Jenkins could do through nifty plugins that GitLab CI cannot do yet. I even wrote one plugin myself for supporting our in-house Linter, really wasn't that difficult and you could hook into pretty much every little detail (which, again, can also be a curse because every plugin had the power to simply crash your Jenkins...).
EDIT: So to be clear, I'm not saying "Jenkins is better than GitLab". I would say GitLab CI is better designed, more robust and stable, but Jenkins is more configurable, extendable and has more features through it's plugin ecosystem. So personally, I wouldn't go back to Jenkins, but I also don't find it ridiculous that people still use it.
A lot of the time when old things are still around, it's not because through all the years nobody has had the idea to replace them, but because the benefit of replacing them hasn't at any point in history outweighed the hassle.
This is true for X11 and this is true for the QWERTY layout. The benefit of switching must outweigh the enormous hassle of doing so. It's easy to find something that's a little bit better, but that's simply not good enough to merit a switch.
Often they're around because when it comes around, they do a such a decent job and it's difficult to actually produce something that has that sort of advantage.
X11 is finally, finally on the way out. I have a lot of gripes with Wayland, but the day I stop needing to dive into xrandr and figure out why the screen is rotated but the mouse coordinates aren't or some other 1990s level problem will be a happy one.
QWERTY seems to be too embedded even for that, but I wonder if it gets closer to replacement the higher the percentage of software keyboards climbs vs physical ones.
> but the day I stop needing to dive into xrandr and figure out why the screen is rotated but the mouse coordinates aren't or some other 1990s level problem will be a happy one.
I'm sympathetic to wanting legacy mindhorrors replaced with modern stuff, but genuine question:
When do you ever have such problems xD
I've multimonitored on X11 for like 4 years and never experienced that.
Have you tried to multimonitor different combinations of HiDPI + regular DPI on x11? Last time I tried to make different scaling displays work together on x11 the experience was so nightmarish that I went back to windows.
I run into problems like that a lot; I guess I do edge case things. That particular example was on an Intel Atom Bay Trail tablet (garbage architecture) I resurrected with a lightweight distro. It was a huge improvement, but there was no support for auto rotation, and manual rotation turned the screen but not the mouse coordinates sent by the digitizer. This meant touch inputs were mirrored or flipped or both.
This wasn't an old-school problem, either, it was three months ago.
Do you know the cost of maintening big old systems ?
There are hundreds of people here for that
I'm not in HR, but I guess that's a lot of money spent each year, just to get the same issues we had last year
It takes a lot of money to not improve the situation
Jenkins is one of those things you configure and forget about...until you need to do it again.
Over time, there's so much stuff that it does that replacing it is a ton of work. And by work I mean verification and communication. Many developers have no idea how stuff gets built, or how dependencies are managed in the build system. You forget one thing and the build is toast. Hunting this info down takes a ridiculous amount of time.
Now expand that to X number of projects, and you're looking at a year of work...and a delay while QA checks everything again.
Why change something that mostly works fine? I don't like to change set of known issues for a set of unknowns.
Also those who want to avoid vendor lock in. Git repo might be moved around, do you like changing CI/CD scripts every time you change your git hosting service?
GHA work really well for simple stuff. For more complex in a larger organization there is no clear winner.
Big companies with data restrictions that can't have anything so much as look at the cloud, and they don't have the skills or money to set up something nicer on prem.
Bitbucket is also a big part of this story.
That results in seeing Jenkins all over the ding-darn place at Boeing, LockMart, RC, L3, NGA, etc.
Of course, all that is thrown right out the window if you wire up the Jenkins instance to the goddamn internet.
I guess that works if you want your jobs to run on a schedule; I prefer push-based (you make a commit, you push it to the central copy of the repo, and it automatically triggers jobs).
Oh they have come up with some new trash I have to learn? Great...
Say you were developing inn Angular and Python. Which one of these "alternatives" should I look in to? ie. Which is most requested by typical requiters?
Jenkins is still inherently more full-featured than anything that just runs random docker images and commands. Any replacement would need to do the hard work of actually integrating with a bunch of different language build tools in a deep way, and so far no-one's stepped up.
It doesn’t work well. It’s the JIRA of CI/CD: it is entrenched and does multiple things but doesn’t do any one thing well, and the people that decide what to buy aren’t the people who are forced to use it so they don’t care about its quality so much
Jenkins is what I want to use, because for all its clunkiness it has a better deep integration with my actual build tools than any other CI tool I've ever seen. It's a pain for the admin but it's great for the user, so if anything it's the opposite of JIRA.
I like that with Jenkins you can use groovy, which gives you some extra power as far as writing commands is considered. You don't have to do everything via shell. Equivalent shell commands can be a bit messy sometimes.
It was a bit painful to write the same stuff in GitHub actions. Jira's groovy script made loops, storing variables very easy compared to GitHub actions' YAML.
