| 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 to be executed with a number of different configurations. If there was better native support for pipelines calling other pipelines, this might not be such a problem. Example: a kube related project. It has a Jenkinsfile for release builds and another for general checkin/PR builds. Each of those need to be tested with two versions of kube, with flannel and calico, with and without RBAC. I don't know of a clean way to do that without Job DSL/JJB and parameterized jobs. In my experience, this type of scenario is not uncommon. We need visibility at the config level. It's not helpful to shove all of that into a single job with coarse -grain reporting up. Even if you put parameters aside, there is just a fundamental mismatch because the pipeline only (today) encodes steps. What about triggers? Having them be part of the pipeline and having the pipeline modify it's own job in Jenkins feels very, very, very wrong to me. There's a reason Job DSL and JJB kept those separate. In fact, if it weren't for the Pipeline visualization, I could've gotten the same functionality with JJB /Job DSL alone, with some bash scripts, with considerably less heartache. I don't know that I know a "lot" about Jenkins, but I do know that I strive for easily repeatable setups that need git triggers, need to post back status, and need to run bash scripts. This most recent attempt was the third time owning it all-up and it was still very tedious. And it was really much easier to achieve this simple requirements with k8s's Prow... Even when having to dive in and hack some of prow's plugins. All of the mature, repeatable Jenkins setups I've seen are small mountains of groovy scripts with their own workarounds embedded. There needs to be a system config DSL too, because maintaining huge blobs of XML and writing groovy.init.d scripts keep me awake at night. Anyway, Jenkins is crazy good stuff, especially for it's age, but for newer smaller projects that don't need the 10,000 Jenkins plugins, it feels unwiedly. I had hope that Jenkins X was going to tackle some of these things, but so far I'm not sure. Thanks again for taking the time, I hope my further feedback is constructive. |
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.