Live data from Hacker News

Jenkins Is Getting Old

itnext.io

121–130 of 340 posts

Re: Jenkins Is Getting Old

#121
post #28

I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…

I'm quite happy with Buildbot.

I'm still on buildbot, but it's definitely showing its age and I'm hoping to move off of it within a year. I've been keeping an eye on Chromium's buildbot replacement, LUCI (https://ci.chromium.org/). It's still light on documentation and the source is very internal google-y (they seem to have written their own version of virtualenv in go). However, based on the design docs it does look like they ran into a lot of the same problems I have with buildbot, specifically the lack of support for dynamic workers, and how underpowered the buildbot build steps can be.

https://github.com/luci/recipes-py/blob/master/doc/user_guid...

Re: Jenkins Is Getting Old

#122
post #22

I receive vulnerability notifications for Jenkins, pretty much regularly... mostly XSS and RCE. https://www.cvedetails.com/vulnerability-list/vendor_id-1586... I'm just waiting for Apache to adopt it, and then it'll sit and fester like everything else in the Apache graveyard, full of vulnerabilities and slowly decaying. Those are just Jenkins core exploits too... there are so many many more for Jenkins plugins.... ht…

Last place I was at had their unmanaged Jenkins servers get compromised and used to run crypto miners.

Re: Jenkins Is Getting Old

#123

I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…

Another "me-too" for GitLab CI. We migrated away from Jenkins to it and it has made life day and night easier. We went from builds and such failing at seemingly almost all the time to builds for Windows and other platforms consistently building and undergoing analysis by other code checking tools

Re: Jenkins Is Getting Old

#124

I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…

> "... has an offensive UI..."

> "... suck massive genitals..."

I cannot believe that this is the top-voted comment.

Re: Jenkins Is Getting Old

#125
post #28

Earlier quoted context omitted.

I'm quite happy with Buildbot.

I'm still on buildbot, but it's definitely showing its age and I'm hoping to move off of it within a year. I've been keeping an eye on Chromium's buildbot replacement, LUCI ( https://ci.chromium.org/ ). It's still light on documentation and the source is very internal google-y (they seem to have written their own version of virtualenv in go). However, based on the design docs it does look like they ran into a lot of…

Doesn't buildbot have dynamic workers implemented as latent workers? [1]

What do you mean by underpowered buildbot steps? Are you implementing your own step classes?

[1] https://docs.buildbot.net/current/manual/configuration/worke...

Re: Jenkins Is Getting Old

#126

I sincerely wish I could move away from Jenkins for the reasons stated in TFA (GUI-oriented, slow, hard to backup/config, test-in-production mentality and boundless plugins) but I've never found something that fits the bill. The much-touted repo integrations (travis, circle...) all have an exclusive focus on build-test-deploy CI of single repos. But when you have many similar repos (modules) with similar build steps…

TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenki…

Of the CI tools I've used (most of them) TeamCity was my personal favorite--but the advantage of Jenkins is that it's very widely used, has a greater breadth of capabilities due to the huge plethora of plugins, and a huge amount of support info readily available online. Some plugins are even maintained by an external vendor that produces the tool you're trying to integrate with and are either better supported or the first to get timely updates.

Bamboo on the other hand is IMO the worst of the commercial CI tools by far and where I work has gone down for us the most. Atlassian itself doesn't appear to be investing in it much anymore judging by the slow pace of development in recent years and at their most recent conference, you can hardly find it mentioned or see much presence for it anywhere.

In all the CI systems I've used though, there has not been one that I haven't encountered some major difficulties with.

Beyond that, anything to do with build automation for a large number of users always quickly becomes a support & maintenance quagmire. Users frequently want to install a new (barely maintained) plugin to solve a problem they have, complex interactions lead to difficult to understand failure modes that require time consuming investigations ("your CI tool is the problem and broke my build" ... "No, your build is broken" ...).

Re: Jenkins Is Getting Old

#127
post #115

Earlier quoted context omitted.

TeamCity from JetBrains is the same thing as jenkins, except the core features are working core features instead of broken plugins. It's paid software though, you get what you pay for. https://www.jetbrains.com/teamcity/ On the other hand there is Bamboo from Atlassian. https://www.atlassian.com/software/bamboo I really don't understand this mentality of there is no better tools when there are better tools than jenki…

TeamCity doesn't handle downstream builds properly. Bamboo has severe stability problems. I've worked at places that evaluated them and always found Jenkins was still the least bad option.

Could I ask you to elaborate on the downstream build issues? Thanks!

Re: Jenkins Is Getting Old

#129

I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…

> " ... has an offensive UI... " > " ... suck massive genitals... " I cannot believe that this is the top-voted comment.

I assumed OP felt that the background UI's fictional butler (a metaphor) is what offended them so I asked why this was the case. Many downvotes ensued.

Re: Jenkins Is Getting Old

#130

I have been with jenkins since about 2010. At its peak I had to shepherd ~50 masters of varying ages, plugins and levels of customisations. Yes, it allowed repeatable builds, and it can be, in certain circumstances a very good replacement for cron jobs where you need to administer >5000 machines. However, it has an offensive UI, the plugin system appears to be designed to deliberately cause things to break, versionin…

GitLab CI is pretty good. I hate, on a fundamental level this whole "bash in YAML" trend. Let's take a powerful, turing complete language and put it in a _config file_. What? I don't even... And the fact that you only get _one_ .gitlab-ci.yml file. That is legitimate madness. Want modularized CI/CD configuration? Not in these parts, buster. Have submodule build dependencies? We laugh at your use case. Sure as shit be…

With newer versions you can include other yaml files.

You can also have templates, special jobs starting with dot.

Post reply on HN