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

241–250 of 340 posts

Re: Jenkins Is Getting Old

#241

Post by djhaskin987 »

FrenchyJiby wrote: post #18

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…

Zuul-ci.org had recently caught my eye, particularly because it fully supports heavy integration testing of multi-repo apps. It doesn't yet have support for bitbucket server though, which is sort of a deal breaker for me.

Re: Jenkins Is Getting Old

#242

Post by michaelneale »

chucky_z wrote: post #221
michaelneale wrote: post #145

Earlier quoted context omitted.

I think this "lesson" is not lost on many, including those that built and work with Jenkins and plugins. The Jenkins X project moved to a very different approach, a fresh start. see https://cd.foundation/ & https://jenkins-x.io (it works with Jenkins if you like, but natively uses the new pipelines and no SPOF masters). Might not be for everyone but worth a look. disclosure: cofounder of cloudbees here (wanted to com…

Why the dependence on Kubernetes everywhere in these new tools?

well as far as I know bash and gcc don't depend on kubernetes yet, but that is a good point.

It isnt' for everyone (and I wouldn't want to run it myself - GKE or EKS is fine but otherwise.. it seems tough to run).

Also this is really a starting point for Jenkins X - I expect options for non kubernetes to be coming.

Re: Jenkins Is Getting Old

#243

Post by michaelneale »

manigandham wrote: post #229
michaelneale wrote: post #131

Co-founder of cloudbees here, just some corrections: 1) there are (since 1 year) restartable builds/stages in open source (a bit over a year IIRC) - when the article mentions that they are not in open source. 2) Jenkins X is something VERY DIFFERENT from Jenkins (despite the name), it is "master less", yes requires a kube cluster to power it, but it has no Jenkins instances as you know it, in a lot of ways quite a bi…

Unfortunately people are looking for simplicity and this is going in the opposite direction. A kubernetes cluster is just offloading a large part to yet another component you have to run. Spinnaker is another completely separate system. This is the opposite of what teams want. Drone, Gitlab, Teamcity as mentioned in these comments is a far better approach for 99% of companies who want a solid working solution.

Agree Kube is not for everyone, no question, I was just trying to clarify what was in the article. (if you are offloading complexity - I would hope it is to a GKE or EKS or AKS or similar, in which case it is very much offloaded...)

I didn't mean to imply that you mix all those things together from the CDF - was just mentioning some interesting projects (some are unrelated) in the mix.

Agree also on simplicity - myself I don't like to run anything, so CodeShip is what we have for that (but it sounds like you are referring to self hosting only solutions?)

(edit: and thanks for insightful comment)

Re: Jenkins Is Getting Old

#244

Post by mrferos »

We use Jenkins at work and have found a pretty damned sweet spot.

Let me start by saying that we used to use GitLab, a lot of it was because of the CI but I didn’t have a great experience trying to manage it on top of Kubernetes, they’ve since introduced a Kube native package and I’ve been told it’s much easier, but with the deployed omnibus we ran into a lot of issues with runners randomly disconnecting, it became frustrating to the point where I had developers not wanting to use GitLab and finding interesting ways to work around it.

So I set up Jenkins on a dedicated EC2 instance with a large EBS volume for workplace storage and installed the Jenkins plugin then I wrote a Jenkins library package that exposes a function to read a gitlab yaml file and generates the appropriate stages with parallel steps that execute as pods in khbernetes - took about a week to get the things we actually used from Gitlab CI and their YAML DSL working correctly.

Now we very happily use Jenkins, mostly through YAML but in the occasions where things are much easier going directly to Groovy to use interface with plugins, developers can.

Re: Jenkins Is Getting Old

#245

Post by mrferos »

mrferos wrote: post #244

We use Jenkins at work and have found a pretty damned sweet spot. Let me start by saying that we used to use GitLab, a lot of it was because of the CI but I didn’t have a great experience trying to manage it on top of Kubernetes, they’ve since introduced a Kube native package and I’ve been told it’s much easier, but with the deployed omnibus we ran into a lot of issues with runners randomly disconnecting, it became f…

I want to specify this is my own experience and I think a lot of our own issues may have been from mismanaging our self-deployed setup. I’ve had a lot more experience managing Jenkins.

GitLab and their approach to CI (easy to use yaml) really facilitated developers writing CI, which increased our software quality overall.

Re: Jenkins Is Getting Old

#246

Post by michaelneale »

chucky_z wrote: post #221
michaelneale wrote: post #145

Earlier quoted context omitted.

I think this "lesson" is not lost on many, including those that built and work with Jenkins and plugins. The Jenkins X project moved to a very different approach, a fresh start. see https://cd.foundation/ & https://jenkins-x.io (it works with Jenkins if you like, but natively uses the new pipelines and no SPOF masters). Might not be for everyone but worth a look. disclosure: cofounder of cloudbees here (wanted to com…

Why the dependence on Kubernetes everywhere in these new tools?

But to your point (sorry I missed it first) - assuming kubernetes is like assuming an OS, you get to do things like preview apps and other benefits.

But if that isn’t for you https://www.cloudbees.com/products/cloudbees-jenkins-distrib... aims to simplify the Jenkins config.

Re: Jenkins Is Getting Old

#247

Post by michaelneale »

manigandham wrote: post #229
michaelneale wrote: post #131

Co-founder of cloudbees here, just some corrections: 1) there are (since 1 year) restartable builds/stages in open source (a bit over a year IIRC) - when the article mentions that they are not in open source. 2) Jenkins X is something VERY DIFFERENT from Jenkins (despite the name), it is "master less", yes requires a kube cluster to power it, but it has no Jenkins instances as you know it, in a lot of ways quite a bi…

Unfortunately people are looking for simplicity and this is going in the opposite direction. A kubernetes cluster is just offloading a large part to yet another component you have to run. Spinnaker is another completely separate system. This is the opposite of what teams want. Drone, Gitlab, Teamcity as mentioned in these comments is a far better approach for 99% of companies who want a solid working solution.

On the point of simplicity, much pain has been described here about running Jenkins - https://www.cloudbees.com/products/cloudbees-jenkins-distrib... is hopefully a better way to handle that.

On kubernetes - imagine if that was already managed for you, all the powerful things that can be done on top vs your self (preview apps, owasp vulnerability testing, progressive delivery - all without writing a pipeline - this is stuff that can be done.

I note gitlab is mentioned a lot here: they noted this power as well (see auto devops) and have started building things on top of kubernetes too.

Re: Jenkins Is Getting Old

#248

Post by michaelneale »

snorremd wrote: post #57
hardwaresofton wrote: post #9

Disclaimer: I'm pretty biased towards Gitlab -- write about the things you can do it from time to time and they gave me some free swag once. Best CI I've ever used is Gitlab CI[0]. The runner is completely open source[1] and you can use your own runner with your gitlab.com (or local instance) projects -- set it up in an autoscaling group[2] for savings. I run https://runnerrental.club but Gitlab also recently release…

If you know a bit about GitLab and Docker, GitLab CI is pretty easy to grok. I really enjoy that you can run your CI jobs inside any old Docker container (with a shell). GitLab CI is built up from very simple concepts and functionalities, but still enables some powerful use-cases. The artifacts feature is great and some artifacts, like unit test report files, can be interpreted by GitLab and used in various parts of…

(Disclaimer: CloudBees cofounder here)

Our hope to simplify away the checkboxing and plugins is ready to go distro (free of course): https://www.cloudbees.com/products/cloudbees-jenkins-distrib...

You mention docker and it is super great for CI: it’s probably one of the widest used feature of Jenkinsfiles (you can specify what image or dockerfile you want a stage to run in - simple but powerful, as you probably know)

Re: Jenkins Is Getting Old

#249

Post by Pokepokalypse »

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…

hm.

same.

Re: Jenkins Is Getting Old

#250

Post by solatic »

jniedrauer wrote: post #148
solatic wrote: post #104

OP really needs to try Concourse. Same container-based workflow as Drone that is touted as a solution, but more mature, and much more testable than Drone. Concourse really hits his requirements for ops-friendliness and testability. It's easy to upgrade because the web host and CI workers are completely stateless, and the work you do with Concourse is easy to test because the jobs themselves are all completely self-co…

The thing that turned me off concourse last time I checked it out is that their documentation assumes (assumed?) you're going to use BOSH. I don't want to have to learn and maintain yet another infrastructure as code tool, just for my build server. I know you can run concourse without it, but all their examples seemed to use it and I didn't want to hit edge cases that they didn't account for. So I gave up before too…

You can get Concourse as a Helm chart and completely avoid BOSH (which is how we deploy it).
Post reply on HN