Live data from Hacker News

Jenkins pipelines as YAML

jenkins.io

1–10 of 76 posts

Re: Jenkins pipelines as YAML

#2
I think it totally makes sense to do stuff like this as long as you keep a very thin layer of abstraction between your YAML declarations and Jenkins config. Like, someone familiar with Jenkins and the naming conventions should easily be able to come in and map what buttons and boxes they fill in the UI to what is declared in the YAML. I’ve worked with several build systems that try to get way too clever with this and all you end up with is huge amounts of config files that only a few people are able to understand and manage (even if there is nice documentation!). Build systems are just as important for following the Principle of Least Astonishment as codebases are.

Re: Jenkins pipelines as YAML

#3
Looks interesting, although it seems very similar to another project, Jenkins Job Builder (https://docs.openstack.org/infra/jenkins-job-builder/) that can describe jobs as YAML or JSON, and is designed one level higher as a meta-jobs creator that can create many jobs all with slight variations, with all of the config kept in version control (no manual fiddling with the Jenkins GUI, other than troubleshooting). With JJB, most jobs aren't pipelines, but traditional Groovy-based pipeline scripts can be included and run.

It would be great if there was a pre-run remote lint step like can be run on Declarative Pipeline jobs (https://jenkins.io/doc/book/pipeline/development/#linter).

Re: Jenkins pipelines as YAML

#5
post #4

ha YAML, when mentioned, always reminds that taking a look at the specs[1] is a great reminder that things can derail badly event without a large committee [1] http://yaml.org/spec/1.2/spec.html

I knew someone in the comments would bitch about it being YAML. So write it in XML or whatever you want and transform it with a script. Jesus.

Re: Jenkins pipelines as YAML

#8
post #6

This would be great if you didn't have to use scripted pipelines for so much stuff. Declarative pipeline isn't there yet.

From what I can tell, this creates a mapping of YAML to Declarative pipeline syntax, so it's unlikely to improve on that.

Re: Jenkins pipelines as YAML

#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. Trivial pipelines take far, far, far too long to setup and get working well.

This just appears to be a layer on top of the still-limited declarative pipelines. I'm not sure trading a groovy DSL for an extra layer (of yaml, no less) is a good deal.

It doesn't solve the weirdness around multibranch, it doesn't address the mismatch between having a parameterized pipeline where that parameterization has to live outside the Jenkinsfile (or if it is encoded in the Jenkinsfile, it acts really oddly, like running the Jenkinsfile actually reconfigures the job that invoked it, etc). This is why everyone has to continue using Groovy DSL and/or JJB to reinstantiate parameterized jobs or handle jobs that deal with multiple Jenkinsfiles in a project.

I know Jenkins isn't going anywhere but it's legacy shows a lot.

Post reply on HN