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. On Monday, December 30, 2019 at 8:16:58 AM UTC-5, Victor Martinez wrote: > > 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 > -- 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-users+unsubscr...@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.
