Live data from Hacker News

The worst thing about Jenkins is that it works (2019)

twitchard.github.io

221–230 of 275 posts

Re: The worst thing about Jenkins is that it works (2019)

#221
post #20

Jenkins is not perfect by any means, but I can say it is much better than existing solutions (taking pros and cons after trying and using many of them). Sure, it doesn't have fancy UI or flying buttons, nor is it rust/PWA/react/whatever-rage-is-these-days, but it does its job - it works, is free, and has been very well-maintained for ages. Download a single file and run it. Want to extend it? There is a plugin for ev…

Jenkins, like many CI tools, is fine when you are maintaining 1-5 builds. Sure, your artisanal bash script pasted into the shell run of the Jenkins gui is stable and it just works. When you go beyond that is when everything falls apart. And by fall apart I mean your org starts to grow to a technical ci debt by a thousand cuts until its taking some teams hours to build and ship their code or debug a spaghetti string o…

+1. Jenkins is only simple as long as your problem domain is simple.

Once you need a tiny bit more, you are screwed. By that time you are already too heavily invested because initial barrier to entry was so low.

Re: The worst thing about Jenkins is that it works (2019)

#222
post #64

I truly, truly dislike Jenkins but haven’t found a better locally hosting CI system that is repo agnostic. My issues with Jenkins: 1. Groovy is a really annoying language to configure stuff in. I’ve never written it for other things but it has so many little idiosyncrasies that catch you out. 2. Jenkins doesn’t have much in the way of resource management. It’s easy for a job to take over the entire node and Jenkins d…

I've written web servers in Groovy for at least 5 years.. Groovy is great, once you get to know it, but some aspects of its design certainly don't "click" for a while. I'd be using a syntax for years when I'd read in some blog post "Oh that's just xyz with a shorter syntax" and I'd go Ooooh! Great little language though, IMHO one of the best for quick prototyping.

I don’t doubt at all that Groovy is great for doing stuff when you’re used to it and spend a reasonable amount of time with it. I’ve heard great things.

But things like the differences between single quotes and double quotes and a bunch of other subtleties like that, make it really frustrating when the only time I use it is updating build logic.

I’d honestly prefer a more consistent language like Python or Lua. Even if I don’t code them all day, they have more resources to lookup and fewer gotchas.

Re: The worst thing about Jenkins is that it works (2019)

#223

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

> Gitlab CI is still the best CI in the game IMO, Oh god, if this is the best CI in the game, I don't want to be part of this game anymore. I work with (as in write pipeline code for) Gitlab CI almost every day and it's absolutely horrible. Not only does YAML lack any type safety whatsoever, but every day I run into yet another open ticket in the Gitlab issue tracker because using a declarative (YAML-based) approach…

I am surprised to hear this as well. We had Jenkins in my previous gig. It worked, but I spend all my time keeping it humming and learnt nothing else. In my current gig, we were a Drone shop. We switched to Harness CI enterprise and it’s worked really well for us. Their hosted builds are pretty speedy!

We did evaluate Gitlab CI but went with Drone. Gitlab CI is not a top 5 CI vendor IMO.

Re: The worst thing about Jenkins is that it works (2019)

#224
post #69

The most interesting part IMO was at the end when op was noting his new company doesn't have teams/engineers create and maintain their own jobs. I've worked lots of different places now and something that's always frustrated me is how reticent engineering orgs are to reevaluate their processes and policies. Like it looks like his first org could have moved on from this problem by adopting the second org's policy. The…

There are tradeoffs. What happens when the CI team is a bottleneck? What happens when you have to frontload tasks you might not need because you’re afraid your release could be compromised? What happens when the CI team says no and it introduces complexity in your system? Or you end up doing “shadow CI” on your machines to avoid conflict and escalation? The complexity has to live somewhere. It is always worth evaluat…

Sure, of course. My point is just that engineering orgs are generally super conservative and thus consistently fall prey to sunk cost fallacies everywhere. In a very irritatingly bureaucratic sense, you have to have a process for improving your processes, or you end up making awful decisions just because they're the least amount of change, and that metric always wins.

Re: The worst thing about Jenkins is that it works (2019)

#225
post #169

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

I'm in the apparently small group of people who ignores 90% of the made & shared features, and push back against making internal ops to depend too much to any particular CI system. We know how to build, package, and release our software, and at work I firmly support that we write those operations as standalone scripts that in principle could even run in the developer's machine itself. Moving them to CI is just changi…

Same. I've also had to do things like migrate CI when a company was acquired, from Travis to Circle and Circle to GitLab in the past. It's very painful to do this if you've leaned into everything the CI service offers.

Re: The worst thing about Jenkins is that it works (2019)

#226

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

In my own project we actively cut down on external CI deps (non-official github actions) as much as possible, it seems incredible unsafe

When we do use an external dep (like in two places for our massive project) we pin it to a specific GIT sha that we manually curated to not contain anything weird

Re: The worst thing about Jenkins is that it works (2019)

#227
post #89

Earlier quoted context omitted.

Our company switched from GitHub / Jira to everything on GitLab because devops had the authority to make the switch and that's what they wanted. PMs now complain that the GitLab "issue board" is nowhere near a replacement for Jira and us devs complain that GitHub had a nicer UX and less stability issues. Can't make everyone happy at once I guess /shrug

The fact that Gitlab Issues aren't a replacement for Jira is a feature IMO. Jira is surprisingly awful at its main job. For example you can't have more than 2 levels of parent/child tasks (compared to Phabricator which has no limit). Changing an issue to a task or vice versa goes via a complex batch update mechanism. Over-configurability means you end up with a gazillion different task states (Done, Resolved, Finishe…

> For example you can't have more than 2 levels of parent/child tasks (compared to Phabricator which has no limit)

They're deprecating Epic and introducing Parent right now in Cloud. Probably to solve this.

Re: The worst thing about Jenkins is that it works (2019)

#228
post #169

Gitlab CI is still the best CI in the game IMO, but GitHub Actions gives it an incredible run for it's money because of how easy action re-use is. I meant to make a blog post about this, but here's a good a place as any: GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece, but it feels like they lose slightly to GitHub on what GitHub does best -- social virality for developers. The problem…

I'm in the apparently small group of people who ignores 90% of the made & shared features, and push back against making internal ops to depend too much to any particular CI system. We know how to build, package, and release our software, and at work I firmly support that we write those operations as standalone scripts that in principle could even run in the developer's machine itself. Moving them to CI is just changi…

Indeed - a whole generation seem to be doomed to learn the hard way the painful lessons of lock-in.

Re: The worst thing about Jenkins is that it works (2019)

#230
post #207

Earlier quoted context omitted.

> GitLab absolutely innovated many hard parts of CI/CD as a platform-native piece As someone who only used GitLabs CI briefly when it initially launched, what hard parts did they innovate on exactly? As far as I could tell, it's a run-of-the-mill CI/CD platform, for better or worse, but nothing I'd call "innovative". But again, maybe since the first time I tried it when it launched, it has changed, and I missed somet…

They integrated in-repo configuration, self-hosted runners, composable workflow definitions, a robust API, and container building and registries for the first time in a CI tool. Of course GitHub came and blew that out of the water with a composable social actions ecosystem. Which was brilliant and remains the killer feature that puts GitHub far beyond reach of other CI platforms, especially now that they've improved…

> They integrated in-repo configuration, self-hosted runners, composable workflow definitions, a robust API, and container building and registries for the first time in a CI tool.

Out of those, I think only "composable workflow definitions" would be one of the features that other CI platforms didn't have, before GitLab even existed as a project. You might want to re-read the history and features of build platforms before GitLab.

Post reply on HN