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

91–100 of 275 posts

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

#91

Post by Ayesh »

tomjakubowski wrote: post #81
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…

Travis and Circle CI predated Gitlab, with YAML-configured workflows checked in to the repository and the ability to use custom images. GitlabCI's innovation was integration: making it a feature of repo hosting.

I moved from Jenkins to Travis several years ago, and Travis's UI and configuration was such a fresh breath. Back then, pretty much _every_ OS project used it because of their generous offerings for open source projects. I agree with this comment that, and from my own experience living through the transitions, Travis CI made a massive leap leveling up the modern CI we have today.

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

#92

Post by allannienhuis »

i386 wrote: post #79
troupo wrote: post #37

Earlier quoted context omitted.

Jenkins BlueOcean is one of the best "fancy UIs"

Thanks! My team and I made that and it was a lot of fun :)

Thank you for building it - it's my go-to jenkins UI. Makes jenkins tolerable :)

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

#93

Post by comprev »

AdrienPoupa wrote: post #86
happymellon wrote: post #53

Interesting, the side snipe about Docker > One of the mostly-false promises of Docker, as it was sold to me by the true believers who introduced me to it, was that, if you do it right, you can run the same docker image, and therefore have basically the same environment in production, in CI, and on your local development machine. I literally have never worked anywhere that hasn't used the same container in dev/test/pr…

PHP dev here, we have extensions for development that make no sense in production, xdebug for example. You need it for breakpoints and debugging in general but it should not be installed in production. So we extend our production image and install it on top of it. Similarly, we include Composer (package manager) in the dev image only as we only need the installed dependencies in production but not the package manager…

Would multi-stage Docker builds not help here? Composer executes in one step and the result artefacts are copied into a "clean" PHP image without Composer installed.

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

#95

Post by redserk »

There are a large number of quirks I’ve had with the Kubernetes runner on Jenkins causing flaky behavior, but when it works, it’s mostly fine after figuring out Groovy. The 1 in 50 time a job needs to be kicked off again due to some strange error is annoying though.

More often than not, I end up creating a sandbox folder in Jenkins and cloning workflows to work on them by hand without having 90 commits of misc errors and typos. This has helped speed up some iteration.

Sort of off topic from the article, I think where almost every single CI engine falls short is the extremely limited scope they cater to - that every job ever made must be solved with the cargo cult ideology where every CI job mustn’t ever have human input, everything must be perfectly automated CI. This is wonderful when it is possible to do, but sucks when it isn’t feasible.

Jenkins’ strength is that it’s actually a workflow engine masquerading as a CI tool, and that gives a lot of flexibility for a number of bespoke processes.

Do you want to wait for someone to click a button to grant permission to run a job because the test might spin up extremely expensive resources and you’d really rather someone baby sit it? Jenkins has you covered.

Or maybe it just isn’t possible (or worth the time) for your team at a point in time to automate all input to a job, so spin up a Jenkins job that lets someone manually specify parameters.

Maybe your flow can trigger a release of software but you want a human to come behind to do a manual once-over as a final check, then also capture who/why approved it.

More CI tools need to accept the reality that not everyone can implement the perfect ideal of CI jobs. Some jobs will require a human step somewhere, be it custom input to a job or waiting for a response.

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

#96

Post by dangus »

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…

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 administer (first-hand experience) where almost every environment will result in plugin hell. I wouldn’t describe the setup process “download a single file and run it” as I look at the documentation, either.

Jenkins can’t give you the “one less tool” advantage that you get with GitHub or Gitlab, either.

Don’t forget that Jenkins’ competition includes free options with mostly high longevity.

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

#97

Post by DylanSp »

happymellon wrote: post #53

Interesting, the side snipe about Docker > One of the mostly-false promises of Docker, as it was sold to me by the true believers who introduced me to it, was that, if you do it right, you can run the same docker image, and therefore have basically the same environment in production, in CI, and on your local development machine. I literally have never worked anywhere that hasn't used the same container in dev/test/pr…

At a recent job, we had slightly different containers for local dev; our backend containers (for a Go app) had Air [1] installed for live reloading, plus Delve [2] running inside the container for VS Code's debugger to connect to. We also had a frontend container for local dev, which didn't get deployed as a container, just as static files.

[1] https://github.com/cosmtrek/air

[2] https://github.com/go-delve/delve/

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

#98

Post by sevagh »

zdw wrote: post #77
sevagh wrote: post #58

Earlier quoted context omitted.

>- Put all build/publish/test logic in Makefiles or scripts in the repo. This means that devs can run it locally as well. The only interaction between a test runner and the codebase should be running `make `. This always breaks because then each platform has a specific way of defining env vars or secrets for those Makefiles and bash scripts. End result is devs still can't really run CI "proper" the way it's configure…

This is fundamentally an interface problem. As you called out Env vars are a pretty common and well supported interface, across multiple platforms. Do you have a better option to suggest?

No, and I don't think any CI platform deals with it in a great way. I mean that once you account for the fact that your dev team may not have access to all of the secrets, the single bash script/Makefile stops being able to shield you from the specific CI platform, and now you have to start using Jenkins secret storage, or GitHub Actions secrets, or whatever.

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

#99

Post by wharvle »

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…

Desktop program UI design mostly peaked in the 90s (search-to-launch becoming ubiquitous is about the only really good thing to happen since then). Desktop web design peaked somewhat later, in the two- and three-column era. ‘00s. It was nice when most sites looked and worked about the same way, and that way also happened to have great info density for a desktop screen.

Mobile web design, I’m not sure it’s had a peak yet. Phone os UI peak was iOS6.

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

#100

Post by twunde »

happymellon wrote: post #53

Interesting, the side snipe about Docker > One of the mostly-false promises of Docker, as it was sold to me by the true believers who introduced me to it, was that, if you do it right, you can run the same docker image, and therefore have basically the same environment in production, in CI, and on your local development machine. I literally have never worked anywhere that hasn't used the same container in dev/test/pr…

I'm general, it's an anti pattern since it's makes everything much more complicated. The typical reason to have it is so that there are dev tools in the dev container (autoformatter, linter etc) or support for hot reloading and then the prod container is locked down. The other pattern you'll sometimes see is that the prod container will include an agent or a certificate bundle, although it's more common to use sidecars for this.

It becomes problematic because it then becomes easy for engineers to have a completely different container for dev then is used for prod. I recently found an issue where a dev container was using a completely different base and had a different version of node installed compared to the prod container

Post reply on HN