Live data from Hacker News

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

twitchard.github.io

211–220 of 275 posts

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

#211
This is my favourite quote:

    The worst thing about Jenkins is that it works. It can meet your needs. With a liiittle more effort, or by adopting sliiiightly lower standards, or with a liiiiitle more tolerance for pain, you can always get Jenkins to do aaaaalmost what you want it to.
This is great, opinionated writing!

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

#212

Having worked with a huge Jenkins deployment at a large company somewhat recently (>10,000 jobs), I found it worked okay enough that company leadership never felt it was worth the pain if switching. But all the friction points added up to a system that was rarely touched by anyone who hadn’t learned where all the bodies were buried. Over time that meant as an engineering org we were underinvesting in CI; there was a…

As someone who has only ever been involved in CI/CD at smaller companies, I take for granted that our pipelines are maintainable by the developers writing the code being tested/packaged. That just seems like a positive indicator for QA culture.

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

#213
post #163

Earlier quoted context omitted.

I really wished we finished it and made it the default UI. Jenkins is very extensible, so there are a LOT of extension points. We certainly didn't have the right approach to the API and devex for creating react plugin extension points either.

We almost made it... Still bums me out. Good to see you're still lurking broseph ;-)

We almost did! It was a huge boulder to move. Nice to see you around too :) lets grab a beer soon

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

#214
post #178

Aside from the docker snipe I've already commented on, everywhere that I've had to deal with Jenkins it's been an issue because it's always a pet. There are always issues, and like the author, it's "only" about 25% of the time. A quarter of all builds fail due to things absolutely not related to that specific build. > oh, we were resource constraint at that one second, retry and it'll probably work > oh, we can't rep…

> oh, we were resource constraint at that one second, retry and it'll probably work Had the same issues with (self-managed) gitlab CI. This is not jenkins-specific and usually something you can fix much easier in jenkins (other than just retrying) > oh, we can't replicate that error message from a tool that you have no visibility over, retry and it'll probably work This could maybe be better in other, more declarativ…

You appear to be reading more into what I'm saying.

I didn't say this was exclusive to Jenkins, just that Jenkins has always been a subset of this problem. Selfhosting this, and wanting to make it completely customised to fit the whim of whatever someone in compliance/security/accounting decided is an issue. It doesn't help that Blue Ocean is a terrible UI, but that's just an ugly facade to a system that enables bad habits. Other systems can be abused, but whenever Jenkins appears it is always abused.

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

#215
post #96

Earlier quoted context omitted.

I don’t think the issue with Jenkins is the lack of bells and whistles. The UI it has is unintuitive - I always feel like I can’t find what I’m looking for anytime I am in there. It has two different UIs (last I checked) which is kind of insane, blue ocean still sucked the last time I used it and the product can’t 100% move away from the old UI (again, last I checked…) On top of all that it’s not really fun to admini…

And Blue Ocean’s effectively deprecated!

TIL. https://plugins.jenkins.io/blueocean/

   Blue Ocean status

   Blue Ocean will not receive further functionality updates. 
   Blue Ocean will continue to provide easy-to-use Pipeline visualization, but it will not be enhanced further. It will only receive selective updates for significant security issues or functional defects.

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

#216

Earlier quoted context omitted.

> However, I think it's less common to run automated testing within the same Docker image you build and deploy to these environments. When you say "automated tests" do you mean unit or integration tests, or both? Because unit should generally be in your compilation process, not part of any image, and integration shouldn't require anything different in the image compared to any other environment. Build it, which inclu…

Great question! In my experience with ruby on rails, the application runtime is so dynamic, that even unit tests may not be reliable if run outside the production image. I think normally this isn't much of an issue because other automated/manual integration testing in the staging environments will catch any major problems, to your point. Another example would be for browser testing via chromedriver. I've usually seen…

> Another example would be for browser testing via chromedriver.

That shouldn't be in your master image. Put your application in a container, and either just run your browser tests and point it at your dev/test/prod deployment, or build a second image with Chrome driver and the test scripts and point it at your deployed application.

Doesn't need to be multi-layer, and it doesn't need to be complex. You have essentially two apps here.

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

#218

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…

Granted, I haven't used Gitlab CI in 5 years, but I would not praise it either. In fact, the entire Gitlab UI and UX annoyed me so much I moved our company repos to GitHub.

The latest redesign where they grouped all the sidebar links into even more categories just made it ludicrously worse.

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

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

> There is a plugin for everything under the sun

Yeah, that's the biggest problem. Almost every thing you need for a CI system comes in the format of a plugin, because Jenkins core is too simple. You can't always say no to your developers' plugin requests, because many of them are actually very reasonable.

Now you install one simple plugin, and it comes with 10 dependency plugins, and that's when your nightmare begins:

- out of these 10 plugins, 4 were owned by some random dudes on the internet and hasn't been updated in 3 years.

- 2 are not compatible with your jenkins core version.

- If you update Jenkins core, 3 other deprecated plugins will stop working.

> IMHO, I don't want bells and whistles from the CI tool.

I can see from the architecture design perspective, Jenkins is simple and boring -- it's a monolithic java app and data is just text files. But I would argue that, its UI is much more complicated and confusing than anything else. You have to install a bunch of plugins to integrate with code repo (github, gitlab, bitbucket...), compute systems (vm, cloud, kubernetes...), you have no choice but install a bunch of plugins, and they changes buttons, menus... I had worked for 3 different companies that used Jenkins, and they felt like 3 completely different websites.

To define a pipeline in Jenkins, your choices are either clickops, or the Groovy big gun. There's nothing in between. I don't have much complain about Groovy itself as a programming language, but if you ask your creative developers to use a programming language to define their CI pipeline, you are gonna see 20 different implementations to detect current git branch name. The biggest Jenkinsfile I have seen has 2000+ lines of business logic. Newer CI products like GitLab CI only allows you to define the pipeline in a yaml file, with a list of very limited directives. That's much more conservative. If needed, one can still run a shell step to capture some weird logic in a script, but that inconvenience is a good enough deterrent.

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

#220
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 weir…

For anyone who thinks JavaScript or yaml has funky implicit conversions and comparison rules, wait until you hear about “Groovy truth”.

Theres also the limitation that functions can be max 1000 bytes or whatever I don’t remember. Managing shared libs and testing them is not easy.

It’s not basically Java at all. Everything is subtly different and will surprise you in the least convenient moment.

Post reply on HN