Jenkins job dsl- any way to dry run before affecting changes?

[red 888]

I opened an SO post (that no one seems to be interested in) https://stackoverflow.com/questions/59314501/jenkins-job-dsl-some-way-to-do-a-dry-run

I use the jenkins job dsl to create my multibranch pipeline jobs. It works great with one glaring issue- safely confirming changes _before_ applying them.

A tool like terraform presents the ideal workflow for this- run "plan" _first_ and see what is going to happen, then run "apply" and make those changes

There is currently no built-in way to do this but are there at least any hacky workarounds? For example is there any way I can wrap the multibranchPipelineJob('example'){} closure or extend it in some way where I could have it output what changes its going to make?

What I want is for my seed job to first output what it's going to change and wait for user input, then if the user confirms make the changes

[Victor Martinez]

I've just seen your comment in the open PR regarding https://issues.jenkins-ci.org/browse/JENKINS-27182

> What I want is for my seed job to first output what it's going to change and wait for user input, then if the user confirms make the changes

IIUC, you would like to mimic a kind of code review similar to the GitHub Pull Request view process, if so, I'd say you can use the proposal from Daniel Spilker (https://github.com/jenkinsci/job-dsl-plugin/pull/395#issuecomment-132346716) with https://github.com/jenkinsci/job-dsl-plugin/wiki/Testing-DSL-Scripts and the pipeline to validate it:

> There is currently no built-in way to do this but are there at least any hacky workarounds? For example is there any way I can wrap the multibranchPipelineJob('example'){} closure or extend it in some way where I could have it output what changes its going to make?

https://plugins.jenkins.io/jobConfigHistory might help you

My two cents

[red 888]

Hey, thanks for the suggestions! I know about the testing framework and while I may wind up using it out of necessity I think dry-run is more valuable than a unit test here. Let me ask you this, could I have a unit test that I could run locally but that that jenkins could also run first before executing the actual job that will accurately output what jobs are going to be changed and what settings are going to change for them? For applying configuration changes like this I think a unit test might be convoluted and overkill.

I agree with daspilker when he out points that the dsl can contain arbitrary code which is not quite the same as a purely declarative language such as terraform but i'm still trying to treat it that way. I have a main entrypoint that reads a bunch of json files to find what jobs and settings to create- so consumers/job creators just need to add an element to a json config to add a new job. A dry run would allow everyone to view what is going to be changed before its changed. This is different then adding a new method or functionality to a class or adding a new feature to an application- this is just config which we want to confirm before applying.

[David Karr]

It seems to me that the only reasonable way to "integration test" pipeline changes before deployment is simply to deploy the changes to a job that is not used for regular work, one that you can manually send events to, to make sure it does what it needs to do.  This is sort of like a "canary deployment", allowing you to do a full deployment, but without affecting regular users and events.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ac15984c-9c36-4266-8f11-5c6f0d778855%40googlegroups.com.

[Lee Meador]

I gain some confidence that my DSL jobs are not catastrophic by building jobs in test folders first. Of course, this does not help when the job builds java artifacts that try to overwrite something real in my Artifactory. And it truly doesn't help when the test job overwrites LATEST in a Docker image. So ... its only useful in limited situations.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAA5t8Vr2HpAEz9ufSLu4UXnUNsSCk2E5F-j4-QNHGdW8QcBbLA%40mail.gmail.com.

--

-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com