Hacker News Reader

Comment by sofixa | Hacker News Reader

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?).

View on HN

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.

“Who still uses Jenkins?”

I think you may have perhaps misjudged just how entrenched Jenkins is in corp/enterprise.

The older I get, the more systems I learn are only around because they've been around.

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.

Doing so literally as I type this. I can confirm it works and has for at minimum 5+ years for me.

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.

Yes? do you know the cost of moving big systems?

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.

For what?

Good luck getting that prioritized.

> Jenkins is one of those things you configure and forget about...until you need to do it again.

And when you do now install and most of plugins is out of date and with security bugs...

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.

Is there an F/OSS alternative to Jenkins that I’m not aware of?

- Woodpecker CI: https://woodpecker-ci.org/

- Drone CI: https://www.drone.io/

- Buildbot: https://buildbot.net/

- Gitea Actions: https://docs.gitea.io/en-us/usage/actions/overview/

- Fogejo Actions: https://forgejo.org/2023-02-27-forgejo-actions/

- GitLab Runners: https://gitlab.com/gitlab-org/gitlab-runner

You could also use Ansible playbooks/roles to run your build, although that's going to be a bit more manual: https://www.ansible.com/

Not necessarily endorsing any of the alternatives, just pointing them out.

How did Apache Maven make it onto this list? Seems like Maven is a build tool that one would invoke _from_ Jenkins or Drone.

That is correct, I removed it from the comment. It's more of an alternative to Apache Ant/make/whatever really.

Which one tells you which test failed and what your code coverage is on one page ?

ssh & Make

Well sure, but ssh and make run from what?

A crontab?

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).

Tekton is a good option -- https://tekton.dev/docs/

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.

What is a better alternative, if you want to self-host?

You can self-host:

- Woodpecker CI: https://woodpecker-ci.org/

- Buildbot: https://buildbot.net/

- GitLab Runners: https://docs.gitlab.com/runner/

- Gitea Actions: https://docs.gitea.io/en-us/usage/actions/overview/

- Forgejo Actions: https://forgejo.org/2023-02-27-forgejo-actions/

- Drone CI: https://www.drone.io/

- CircleCI (not free nor open-source, but self-hosted): https://circleci.com/pricing/server/

- GitHub Runners (same deal as CircleCI): https://docs.github.com/en/actions/hosting-your-own-runners/...

jenkins is old and crusty, but it works and works well. if the UI for a build tool looks too fancy, my faith in it drops to 0 almost immediately.

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

Jira sucks, but I have yet to see a tracking tool which sucks less.

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.

It's not great CD bit you need entirely different system just to display code coverage in near-every other CI

Near-every other CI also can't just browse which tests failed and with what message without digging directly into logs

Genuine question: what would you recommend instead of JIRA?

Builtin code coverage and test display (not just "your build failed") is still not a thing in Gitlab/Github CI

And that's like the fucking basic feature every CI/CD should have.

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.

People doing embedded testing use Jenkins still. Not that I would, but some people do.

Embedded people are pretty pragmatic and tend not to chase fads for the sake of change or resume engineering. If it works, it's good enough for them.

Switching away from Jenkins would cost effort and offer no competitive advantage to your end product, so then why do it?

That's what you took away from the question?

Jenkins still lives in legacy, and probably will for some time.

github has had service issues at least for the last 3 days.

Fun times.

People who have convinced their boss that GitHub downtime means they should create their own shoddy self-hosted CI platform.

Reply on news.ycombinator.com