Re: Jenkins job dsl- any way to dry run before affecting changes?
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.
On Mon, Dec 30, 2019 at 11:36 AM David Karr
wrote:
> 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.
>
> On Mon, Dec 30, 2019 at 8:03 AM red 888 wrote:
>
>> 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
>>
>> .
>>
> --
> 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/CAA5t8Vr2HpAEz9ufSLu4UXnUNsSCk2E5F-j4-QNHGdW8QcBbLA%40mail.gmail.com
>
> .
>
--
-- Lee Meador
Sent from gmail. My real email address is lee AT leemeador.com
--
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/CAA4vtDTcRVj-n5N_3jd%3D0HVeqEC3fMiAZtqnL3E9_B55Y2AMBg%40mail.gmail.com.
Re: Jenkins job dsl- any way to dry run before affecting changes?
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.
On Mon, Dec 30, 2019 at 8:03 AM red 888 wrote:
> 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
>
> .
>
--
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/CAA5t8Vr2HpAEz9ufSLu4UXnUNsSCk2E5F-j4-QNHGdW8QcBbLA%40mail.gmail.com.
Re: Jenkins job dsl- any way to dry run before affecting changes?
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.
Re: Jenkins job dsl- any way to dry run before affecting changes?
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/21df7215-6481-45bc-b93f-af89a8be163c%40googlegroups.com.
Jenkins job dsl- any way to dry run before affecting changes?
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
--
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/c24372bb-f210-4449-8993-691a9bb941dc%40googlegroups.com.
