Live data from Hacker News

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

twitchard.github.io

11–20 of 275 posts

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

#12
Jenkins has improve a bot. before github action has self host runner, Jenkins has worker node years ago.

using jenkins declarative pipeline, almost everything can explain in code.

updating jenkins is a walk in the past.

the most tedious part is dealing with no longer maitenance or support plugin.

make sure to never expose jenkins out. use a relayer to bring webhook traffic in

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

#13
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"

> TeamCity Professional is free – even for commercial use – and has no limitations on features, number of users, or build time.

Yeah, no. There's obviously gonna be a catch in the future.

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

#14

Jenkins works... No it dosen't or maybe it does for java which I don't care about. The ui looks like from the 90s. Finding anything in bigger projects/companies is impossible... I have browser bookmarks to find anything. The log view is annoying at best. I have nothing good to say about jenkins, it feels like it is stuck in the 2000s and refuses to change.

"refuses to change". Is there an active team working on it or is this anthropomorphism of a software project?

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

#16
All of the test runners have their issues. I've had as much problems with Jenkins as I've had with Github Runners and similar solutions.

The best way out of this is to subdivide responsibilities:

- 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 `.

- Put all permissions and code checkout and artifact publishing credentials in the test runner, but no logic. At most you would put processing of test output like making junit/coverage/tap more web-readable.

That's it. Split the efforts cleanly, and things fall into place. Also, you can switch runners easily - less needs to be reimplemented in whatever runner config DSL is picked.

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

#19
> “everybody should be writing and maintaining their own CI jobs”

And, of course, everybody should be using whatever language and version they want to, and run their software on whatever cloud they want. The notion of this makes me super uneasy, but at the same time it's a good explanation why many big orgs have 100s of engineers when they can probably easily do with 10s of them.

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

#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 everything under the sun (but be careful, you can easily bloat it).

IMHO, I don't want bells and whistles from the CI tool. CI tools are dry; I see them as a car drive shaft - it must work properly, and I don't expect it to be pretty. If you need to showcase it, you are probably doing something wrong.

And one more thing: I expect Jenkins to be around and free in the next 10 years. I doubt that will be the case for "insert-your-favorite-ci-from-some-company".

Post reply on HN