Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitchard.github.io

Post reply on HN
Print view View original

111–120 of 275 posts

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

#111

Post by bluGill »

enlyth wrote: post #89
theptip wrote: post #72

> The head of SRE championed Gitlab CI. I resisted this idea because I, the relatively inexperienced manager of a nascent team, was daunted by the prospect of trying to supplant Jenkins, Github, and JIRA all at once. I think this is a really big scoping mistake. There is a clean glide path, and I have no idea why you'd think you need to replace Jira. You can use Gitlab Runners in Github ( https://docs.gitlab.com/ee/u…

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

What management and what devs need from an issue manager is very different. Which is why every 5-10 years everyone wants to switch to a simpler tool, then slowly most of the complexity in the first tool gets added back as the people who needed that one feature complain loud enough, until the people who wanted simplicity become the loud voice and you switch to a simpler tool. It is never the tools fault above. (Some tools are better than others, but the real problem isn't the tool)

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

#112

Post by fullspectrumdev »

lacrimacida wrote: post #15

I had a gig (circa 2014) where Jenkins was used in atrocious ways where it was basically running the show. Yet there were no problems with Jenkins itself, it was running smoothly

I’ve found that people will use CI tools like a hammer once they get them working - everything’s a nail, even screws or bolts.

You often end up with these glorious Rube Goldberg machines where Jenkins does everything and becomes a single point of failure - if the instance falls over, everything’s fucked.

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

#113

Post by indymike »

dangus wrote: post #65
xp84 wrote: post #24

Earlier quoted context omitted.

The 90s were the last actual advance in UI design anyway. Design has drifted in a terrible direction, in the past decade or two especially. Some of this is justified (by some) by optimizing for mobile, but that’s precisely the kind of thing I wouldn’t want creeping into my CI tooling anyway. I don’t do that on a phone.

This idea that design peaked in the 90s does a big hand wave over a whole bunch of horrible examples of the user interface from that era. Is the Space Jam website peak UI design? What about Microsoft’s “hell of tabs” settings dialog boxes? Or the original Amazon home page: https://www.versionmuseum.com/images/websites/amazon-website... What link do I click to find my order status? Where do I go to search for a book b…

Confusing web design and desktop UI design in the 90s does little to dispute the assertion that desktop UI design peaked in the 90s. In the late 90s, the browser was completely new - so there was a lot of skeuomorphism, borrowing from other media to try to make the web work well. Space Jam's format was familiar, though to users of multimedia CD-ROM and other interactive hypermedia of the era.

The desktop application GUI - which is really what people are claiming hit the peak in the 90s, really did. Menus, windows, tabs, dialogs, scroll bars etc... all were fairly well settled, and users understood them. A user who knew Word for Windows could do pretty well using WordPerfect for Windows. Most day-to-day applications were pretty easy to figure out because discoverability was very well done, and wizards and how-to dialogs helped users through the rough bits.

There was consistency between applications - save in areas where the OS didn't really provide GUI guidance - so design, CAD, and other creative apps (hi, Adobe) often had divergent ways of doing things and came with a steep learning curve. The web took off because it actually worked a lot like the multimedia CD-ROMs that preceded it - and websites were a lot easier for developers to build.

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

#114

Post by Jnr »

solardev wrote: post #52

Does Jenkins let you test workflows locally? That's the thing I hate that about CircleCI, Github Actions, etc... having to "commit, upload, wait" to test every minor change =/

I put all the important steps in scripts (makefiles or as commands in package.json for JS projects) which can be run without Jenkins. Pipeline in the Jenkinsfile only runs those steps separately in the correct container build stage to collect separate step results.

If done correctly, the Jenkinsfile should be easy to read by a person who has never written a Jenkins pipeline before.

With this approach it is hard to mess things up by creating a monster pipeline which no one can understand, and if necessary, you can quickly change to different CI runner at a later point in time.

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

#115

Post by drewcoo »

dig1 wrote: 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…

The thing that made me want to use hosted CI was realizing how much time I ended up spending on Jenkins infra and debugging. Upgrades to master or to plugins and then testing them - bleh!

GitHub's being slow? Well that's a GitHub problem. Look, it's been ack'd and they're working on it! Job done.

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

#116

Post by FireBeyond »

lacrimacida wrote: post #15

I had a gig (circa 2014) where Jenkins was used in atrocious ways where it was basically running the show. Yet there were no problems with Jenkins itself, it was running smoothly

Yes, one multinational company who was a customer at my last employer lamented their "dystopian Jenkins hellscape", "glued together with 300+ Python scripts".

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

#117

Post by starttoaster »

capableweb wrote: post #68
hardwaresofton wrote: post #55

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 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…

Innovative is a strong word, but they always had the best support for a variety of deployment archetypes, including baremetal, kubernetes, docker, docker+machine (autoscales VMs in a public cloud to run many Docker executor runners.) They also had JWT authentication support built into GitLab before GitHub even had a CI offering at all. The GitLab kubernetes agent makes their CI/build tool more like a CD tool for organizations that primarily deploy to kubernetes clusters, which is fairly unique for a CI tool to act as a CD tool, though with scripts people often just make the CI tools do deployments anyway.

My experience is limited to GitHub Actions, GitLab CI, and Jenkins. I've never been in an organization that managed to crack the code on running Jenkins in a sane way (always a poorly maintained, bloated mess of plugins, unfortunately) so I can't say I count Jenkins as a contender in this conversation. One could argue it's unfair to discount Jenkins because of organizations that manage it poorly, but there's something to be said about a tool that is so easy to accidentally run in an unmaintainable way. I also have some limited experience with Drone and Circle, but not enough to talk about them confidently.

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

#118

Post by IshKebab »

enlyth wrote: post #89
theptip wrote: post #72

> The head of SRE championed Gitlab CI. I resisted this idea because I, the relatively inexperienced manager of a nascent team, was daunted by the prospect of trying to supplant Jenkins, Github, and JIRA all at once. I think this is a really big scoping mistake. There is a clean glide path, and I have no idea why you'd think you need to replace Jira. You can use Gitlab Runners in Github ( https://docs.gitlab.com/ee/u…

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, Finished, Closed, ...). You can't do basic things like reorder the backlog based on priority.

Perhaps most critically the interface is just insanely slow! It regularly causes waits in sprint meetings while we wait for someone to drag & drop an issue or for the page to load.

The only reason it's popular is because PMs like to make engineers do their job for them so they can just click a button and get pretty graphs that they can copy & paste to presentations.

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

#119

Post by bigstrat2003 »

demizer wrote: post #35

Jenkins is rock solid. Been using it for three years to deliver highly critical software. The development experience is the worst of all ci tools since no one wants to setup jenkinspipelineunit to test the pipelines. Dagger might be the salvation here, but even that tool didn't support Jenkins out of the gate. And for those that are reading this, the statement about pipeline groovy being a trap is exactly right. Avoi…

> And for those that are reading this, the statement about pipeline groovy being a trap is exactly right. Avoid writing groovy at all costs.

I disagree with this pretty strongly. I've worked with Jenkins where it was all freestyle jobs and it was a nightmare to maintain. Pipelines written in groovy are essential to doing Jenkins well, imo. It's also not exactly hard to write groovy. It's basically Java, not some weird esoteric language nobody knows.

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

#120

Post by Smaug123 »

krick wrote: post #70

Well, to be fair, pretty much each of these points apply to all other CI tools in existence.

Jenkins is, like, uniquely awful though. Aside from the sheer staggering number of bugs in its core functionality (I encounter on average maybe one bug per new pipeline I write), it is also configured in almost the worst language I've ever touched (considerably worse than Nix, for example, which is really saying something). "Blue Ocean is Incomplete and Unintuitive" is entirely correct - you have to drop back to the old interface for essentially everything, and also Blue Ocean has the absolutely unforgiveable behaviour that it responds to any ESC keypress, even if the OS has focus.
Post reply on HN