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

Jenkins pipelines as YAML

jenkins.io

Post reply on HN
Print view View original

71–76 of 76 posts

Re: Jenkins pipelines as YAML

#71

Post by slavik81 »

kohsuke wrote: post #63

Creator of Jenkins here. First of all, this is a Google Summer of Code project. Abhishek, who is driving this work, is doing a great work, so I hope people can give him encouragements and feedbacks to push him forward. I'll make sure he sees those feedbacks and will stop by to answer questions you might have. This is one of the efforts that is pushing the envelop of Jenkins that solve problems people had with Jenkins…

Jenkins Essentials sounds great. I've become very good at not breaking Jenkins installations. Jenkins is a powerful tool, but it's hard to recommend when that's a skill you must acquire.

I remember when I installed the git plugin, which forced the credentials plugin to update, which caused runtime failures in communication with some other core plugin, so we reverted the install/update, which broke the whole system because the update had renamed fields in the configuration and the old version didn't understand them...

Since then, I have always updated all core plugins together in lockstep. Based on the name and description, that sounds like what Jenkins Essentials would do too. If so, that's a good sign.

Simpler, more reliable administration is exactly what Jenkins needs and you seem to have a credible way of achieving it, so I'm excited to see the results.

Re: Jenkins pipelines as YAML

#72

Post by kabes »

rollulus wrote: post #28

I'm wondering, who uses Jenkins nowadays and why? A few years ago, at one of my first gigs in an enterprise environment, I used Jenkins for the first time to test and build my stuff. When I needed a newer version of my compiler or specific linter, some fellow had to install that on the VM that was running Jenkins. Later, working in a more modern environment, we started using Gitlab CI. It was a bliss. I specified the…

Jenkins strength is also its weakness. It's like a swiss army knife that, especially combined with plugins, can do just about anything in any way. This makes it hard to find support, best practices etc.

Anyway, you can also have your jobs completely run inside containers, but apparently they chose not to do that in your first job (or containers where simply not a thing yet). See: https://jenkins.io/doc/book/pipeline/docker/

Re: Jenkins pipelines as YAML

#73

Post by kabes »

KaiserPro wrote: post #44
rollulus wrote: post #28

I'm wondering, who uses Jenkins nowadays and why? A few years ago, at one of my first gigs in an enterprise environment, I used Jenkins for the first time to test and build my stuff. When I needed a newer version of my compiler or specific linter, some fellow had to install that on the VM that was running Jenkins. Later, working in a more modern environment, we started using Gitlab CI. It was a bliss. I specified the…

We use it because of legacy. Its fragile, un-updatable and virtually un-automatable. Use plugins? They'll break. Use JJB to make things repeatable? Someone has made a change in the GUI. At last count we had something like 70+ jenkins masters (because we couldn't share slaves, because people kept on cocking up the master.) The rise of circle-CI style yaml interface is wonderful. The build script is there in the repo,…

What's the difference between circle-CI yaml files with declarative jenkinsfiles (except from groovy vs yaml)?

Re: Jenkins pipelines as YAML

#74

Post by KaiserPro »

kabes wrote: post #73
KaiserPro wrote: post #44

Earlier quoted context omitted.

We use it because of legacy. Its fragile, un-updatable and virtually un-automatable. Use plugins? They'll break. Use JJB to make things repeatable? Someone has made a change in the GUI. At last count we had something like 70+ jenkins masters (because we couldn't share slaves, because people kept on cocking up the master.) The rise of circle-CI style yaml interface is wonderful. The build script is there in the repo,…

What's the difference between circle-CI yaml files with declarative jenkinsfiles (except from groovy vs yaml)?

a few things: 1) plugins, they routinely break, the API they provide breaks, functionality changes, or the API they rely on also changes. Its a mine field.

2) bootstrapping a _secure_ jenkins server to the point where its able to accept jobs is a monumental faff. (gitlab runner is far far more simple, if you want Uber free, circle CI if you don't mind paying)

3) its just so much _effort_

Jenkins was great compared to the field in 2010/1 (after it forked changed from alfred) ever since it's failed to move in the right direction.

It over complicated what is essentially a cron/at daemon with web gui.

Re: Jenkins pipelines as YAML

#75

Post by AnthonBerg »

AnthonBerg wrote: post #25
colemickens wrote: post #9

This is highly confusing to me. Pipelines in Jenkins are fragile. You can spend entire days trying to do very common things and run into tons of friction. The differences between scripted and declarative are severe, in terms of how erros and continuation are handled, the way that plugins interact depending on how you've nested stages and steps. Even things like environment vars and CWD can be a pain to coordinate. Tr…

Jenkins can stay. I'm going.

Due to a downvote, I want to reaffirm my position as stated.

Re: Jenkins pipelines as YAML

#76

Post by kohsuke »

colemickens wrote: post #68
kohsuke wrote: post #64

Earlier quoted context omitted.

First, full disclosure, I'm the creator of Jenkins. I'm sorry to hear that you had a bad experience with Jenkins Pipeline. I can see that you know a lot about it. There's actually no difference between how continuation is handled between scripted and declarative, so I'm curious to know more about what hit you, because I suspect it's something else (though obviously equally frustrating!) Similarly curious about improv…

Thanks for the response. Mine is a bit terse as I'm on mobile for a few days. For one, the always/finally block in declarative pipelines flatly doesn't work in scripted mode. You have to set/maintain job status yourself and throw/catch. It's very unpleasant. I am shocked to hear that parameterized builds are in decline. Every project I've seen or touched that used Jenkins had multiple pipelines in a repo that needed…

Thanks, this is really helpful.

I need to find someone from the pipeline team to pull into this, so in the mean time, just responding to what I can contribute,

Just to make sure, I'm not saying parameters are disappearing. I'm just making an observation that less people seem to be using it. Take your example of release vs general checkin/PR builds. I see increasing people doing releases as automation that kicks in after creating a tag, or by cutting a release branch. Or the master branch is always deployable.

I agree with you that reporting capability needs to be better in order for one Jenkinsfile to pack lots of different test cases. I believe the team totally gets this importance.

The "system config DSL" you mention has evolved into "Jenkins config as code", and I've referred to it in my other comment. I think we are on the same page that it's a crucial part of a repeatable mature Jenkins setup. I think I also totally get what you mean by "unwieldy", and Jenkins Essentials in that comment is making steps to attack that challenge.

I'd love to hear from you where Jenkins X fell short for you, because I think it should speak to some of the challenges by embracing a certain best practices.

Post reply on HN