Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jenkins Is Getting Old

itnext.io

Post reply on HN
Print view View original

181–190 of 340 posts

Re: Jenkins Is Getting Old

#181

Post by garenp »

staffordrj wrote: post #165
exelius wrote: post #120

Earlier quoted context omitted.

Agree in all cases. Bamboo was actually ok for a little while; but then they got rid of the cloud version which made it a bit more niche. I also like to plug VSTS in these conversations. It’s really nice to be able to drill down from feature roadmap to build status in a single tool without a lot of config. I haven’t built anything complex in it personally, but hear nothing but good things from the teams I work with w…

> but then they got rid of the self-hosted version What do you mean by this? Is this not the self hosted version? https://www.atlassian.com/software/bamboo/download

They misspoke - it's the cloud version they got rid of.

Re: Jenkins Is Getting Old

#182

Post by bogomipz »

sudofail wrote: post #100

What I'd like to see is a CI/CD engine backend. Most CI/CD solutions have relatively the same feature set: - Code builds - Code deploys - Git Hooks - Parallel builds - Matrix builds - Build as configuration - Etc If there were an engine that supported these features, the community could create a number of frontends that target their specific needs. Jenkins was held back, in my opinion, for a number of years by its an…

What is a "matrix build" in the context of CI/CD?

Re: Jenkins Is Getting Old

#183

Post by mechastorm »

jennbriden wrote: post #142

Hello, I see a lot of great feedback in this post. I am a product manager working at CloudBees, the primary corporate sponsor of Jenkins. Jenkins is now in the Continuous Delivery Foundation as well. While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part o…

I think its already mentioned about Jenkins Configuration as Code. But in general stick to a configuration method, I have had to migrate from JJB > groovy scripts > init.d groovy > Jenkinsfile.

And can we PLEASE open up the issues tab on the Github repos especially for plugins. There is currently no way to provide any feedback/report issues on these plugins because the "issues" tab is disabled. Our current options are - Put a comment on the plugin wiki page - Hunt down the the relevant support forum for the plugin - Find the original source repo and post an issue

All of which are not ideal and does nothing to directly help the development of the plugins.

Re: Jenkins Is Getting Old

#184

Post by Iwan-Zotow »

dvtrn wrote: post #80

I'm not at all ashamed, nor a single bit remorseful to comment on the fact that it took a catastrophic data loss for a team I once worked with to finally sit down and look at our CI/CD pipeline before deciding "Maybe jenkins is overkill for what we need". Which was something I had been kvetching about for months and expressly warned, multiple times to our release manager as a point of concern given how quickly plugin…

WHat do they/you use now?

Re: Jenkins Is Getting Old

#185

Post by bonestamp2 »

exelius wrote: post #120
KaiserPro wrote: post #95

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…

Agree in all cases. Bamboo was actually ok for a little while; but then they got rid of the cloud version which made it a bit more niche. I also like to plug VSTS in these conversations. It’s really nice to be able to drill down from feature roadmap to build status in a single tool without a lot of config. I haven’t built anything complex in it personally, but hear nothing but good things from the teams I work with w…

I agree that we were disappointed when they dropped the cloud version, but we started hosting it ourselves and couldn't be happier. Works much better than Jenkins did for us.

Re: Jenkins Is Getting Old

#186

Post by stan_123 »

No mention of Jenkins Shared Libraries? When Jenkinsfile pipelines start getting complex, or need to make them more generic, you can create groovy lib-s in a separate repository. Single line to load the lib dynamically at start of Jenkinsfile. Then you can call library functions/tasks passing appropriate params within your pipeline. But as anything Jenkins, documentation lacking or out of date.

Re: Jenkins Is Getting Old

#187

Post by lbotos »

majkinetor wrote: post #133
KaiserPro wrote: post #95

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 is awesome, its impressive what you get for free. Runners are nice, can run in powershell, bash, docker, vm , you name it. The main problem with runner is that you cant easily execute build script on the host. Exec command isn't very useful and AFAIK deprecated.

I'm confused at what you mean here. If you want to run things on the host you can run a bash runner, and you have full access to the machine.

What do you want to do on the host?

Re: Jenkins Is Getting Old

#188

Post by l0b0 »

KaiserPro wrote: post #95

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…

It's a clear sign that we're learning as a community, and that open source really does enable innovation[0]. Someone builds Useful System iteration 1, we all learn what part of it works and doesn't, and someone builds iteration 2 because it scratches their itch. Repeat for goodness.

[0] It's unfortunate that big open source projects are never willing to pivot when fundamentals of the original design are shown to be bad. Rarely used features, for example, are never removed in order to make the software better for the overwhelming majority of users.

Re: Jenkins Is Getting Old

#189

Post by mynegation »

Jedd wrote: post #170
core-questions wrote: post #138

Earlier quoted context omitted.

> I hate, on a fundamental level this whole "bash in YAML" trend. This is why I hate Ansible. Looks simple until you need to do something complex, and then it becomes horrible. Chef's use of an actual language is far better, though on the flip side it's much harder to provide any kind of interface to configure it outside of a text editor. If only there were some language where config data and code were the same data…

> If only there were some language where config data and code were the same data structure. (hmmmmmm) Do you perhaps mean syntax rather than structure? (Or a subset of the syntax.) If I've guessed correctly, that language has already been wedged into lots of places that it's a poor fit, so I guess there's precedent there.

I am pretty sure Lisp was wedged into some places where it is a poor fit, but “lots”? Did you guess Javascript by any chance?

Re: Jenkins Is Getting Old

#190

Post by pnathan »

jennbriden wrote: post #142

Hello, I see a lot of great feedback in this post. I am a product manager working at CloudBees, the primary corporate sponsor of Jenkins. Jenkins is now in the Continuous Delivery Foundation as well. While it is easy to bash on an inanimate object, there are some very dedicated and empathetic people who care deeply about the project. Some of those people do this work in their off-hours and some to this work as part o…

I've been involved in pioneering Jenkins, maintaining Jenkins, and using Jenkins for the past 7 or so years off and on in different roles, often that of the Jenkins admin. The original article has a lot of good feedback that I'd suggest addressing; it hits a lot of the pain points I've had in the deploys I've had my hands in.

For myself, I'd prioritize -

An indepth improvement of the Config as Code system as applied to Kubernetes, both for management of the config and of relevant plugins.

Plugin compatibility and management of plugins. It's not... smooth.

Post reply on HN