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

131–140 of 275 posts

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

#131

Post by dzhiurgis »

pharmakom wrote: post #85
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…

I find GitHub Actions incredibly counter-intuitive, personally.

It’s the confusion between actions(basically third party plugins) and workflows(the ci that you are building for yourself) that got me.

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

#132

Post by jamesu »

I stayed away from jenkins for a long while because of its bad reputation, but after diving into it for a recent project I was surprisingly impressed how easy it was to set everything up (with the docker image at least), and it seemed that there was a solution for just about every convoluted build scenario I could come up with. In contrast, I've tried out other tools and encountered: confusing uis, too much focus on docker, broken interop with forges, poor documentation, too much yaml, ...

I guess the flexibility with jenkins is probably both a blessing and a curse.

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

#133

Post by ambicapter »

dzhiurgis wrote: post #131
pharmakom wrote: post #85

Earlier quoted context omitted.

I find GitHub Actions incredibly counter-intuitive, personally.

It’s the confusion between actions(basically third party plugins) and workflows(the ci that you are building for yourself) that got me.

Thank you for finally explaining this to me (have had to deal with github ci off and on for months now).

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

#134

Post by gjvc »

callmeal wrote: post #46
gjvc wrote: post #2

Avoid Jenkins, and if you can, try https://www.jetbrains.com/teamcity "TeamCity Professional is free – even for commercial use – and has no limitations on features, number of users, or build time. It allows you to configure up to 100 builds and run up to 3 builds in parallel, which is more than enough for most projects"

>configure up to 100 builds and run up to 3 builds in parallel Funnily enough, Jenkins does not have that limitation.

It has plenty of others which more than make up for it though.

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

#135

Post by chologrande »

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…

How is Gitlab CI materially different from the jenkins model?

I find that the only difference is that it's YAML - so even harder to debug, and maintains the same model where you must re run an entire pipeline every commit to test functionality.

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

#136

Post by _whiteCaps_ »

flimsypremise wrote: post #90

The real failure here was the failure to recognize the sunk cost fallacy. My team attempted the pursue the "supported" path with Concourse for a recent project, and I watched them bang their heads for a week, realized it wasn't going well, set a meeting where we all discussed and decided to move to GitHub actions. Now everyone is happy and the project is back on track and I don't have a write a blog post like this on…

I really like Concourse but unless you've got someone who's fully drunk the koolaid, it can be hard to a team onboard. It's got some very strong opinions on how builds should be deterministic. "Why can't I just click re-run this failed job!?"

If you're doing something that doesn't line up with Pivotal / Cloud Foundry workflows, you're probably going to have a bad time.

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

#137

Post by chologrande »

The blog perfectly sums up the feelings of anyone who has worked deep in jenkins. It works, but goddamn it's hard not to hate.

Dagger is the answer to jenkins woes. It's saved my sanity and made CI development tolerable again.

* Real language support. No groovy, no yaml.

* Debugging available in your native IDE tools.

* Clear docs in any language of your choice.

* Reproducible builds you can run locally. Just need docker.

This all comes with the bonus that it can actually just consume GHA yaml with some of the tooling folks have made.

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

#138

Post by fullspectrumdev »

hedora wrote: post #121
fullspectrumdev wrote: post #107

Earlier quoted context omitted.

I’ve worked at some places that were pretty huge, but the finance department absolutely fucking nickle and dime over everything . Even the smallest EC2 instances had to be accounted for with a business reason that they would accept, with audits happening every few days. Asking for a licence for something upfront was like pulling teeth.

I’ve encountered this too. I always wonder why the eng departments never itemize the time they spend dealing with finance, then bill the finance team for the hours.

I’ve threatened to do this to a sales department - send them a bill for lost time, engineers working overtime, etc because they sold shit without a clue if it even was possible.

Lead balloons have flown better than that idea did :)

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

#139

Post by dharmab »

roland35 wrote: post #127
john-tells-all wrote: post #66

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. This is critical! In many teams Devs are "lazy", if any errors or weirdness happens in CI they just wave their hands and say "not a feature, not my problem". Even though they know exactly what's in the test code, the deploy code, and can see the issue. Letting Devs see and run the CI scripts loca…

It also takes a lot less time to fix the tests locally too - rather than tweak it... push the change... oops it failed again... repeat...

This still happens, but the surface area is greatly reduced to figuring out that the directory, variables, credentials, dependencies between stages, etc. are set up correctly

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

#140

Post by twitchard »

shadycuz wrote: post #63

> On a previous team I had used Concourse CI to some extent, but I wasn’t really blown away by the experience. Travis and Circle were mentioned. I was a fool. I should have committed to seriously researching some of the contenders and making a more informed decision, but I lacked the willpower and the discernment. The whole post can be summed up as he had very little CICD experience. Made lots of beginner mistakes, w…

This is "the worst part of Jenkins is that it works".

You shouldn't judge a developer tool by just what is possible to do with the tool. After all, with a little turing-completeness it is possible to do anything with anything -- you should judge the tool by what is easy to do with the tool. A good developer tool shouldn't require knowledge of a bunch of arcana to "configure correctly". A good tool protects you from "rookie mistakes" and makes sane choices the intuitive and obvious path of least resistance. Good tools can have a learning curve, but they assist the learning curve by making their abilities easy to discover and experiment with, they don't require you to dig into source code or do random searches on github to find some random pipeline somewhere that uses the configuration you need, as described in the post.

Post reply on HN