POTD: Jenkinsfile Runner

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

POTD: Jenkinsfile Runner

Kohsuke Kawaguchi
Administrator
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xMgdsJRdjTMH-U%3DRUbvopDqiAm4o3r9AjdbjuPTmFnow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Kohsuke Kawaguchi
Administrator
And of course I forgot to have the link to the project! https://github.com/kohsuke/jenkinsfile-runner 

On Thu, Mar 1, 2018 at 11:22 AM Kohsuke Kawaguchi <[hidden email]> wrote:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi
--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4y9e33M%3D%2Bd7umCtauMSCSaH1TkJM_UYhnSqHdH_G3VrHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Jesse Glick-4
In reply to this post by Kohsuke Kawaguchi
For the third use case, what might be useful is an archetype or two analogous to

https://github.com/jenkinsci/archetypes/tree/master/scripted-pipeline/src/main/resources/archetype-resources
https://github.com/jenkinsci/archetypes/tree/master/global-shared-library/src/main/resources/archetype-resources

which use the Docker packaging and take care of all the boilerplate
needed to have a Maven module which, when “built”, runs the specified
`Jenkinsfile` or library against some test inputs in a well-controlled
environment, and presumably passes or fails according to some
conditions. (For example, Groovy validation scripts, akin to Maven
Invoker?) I think the hard part would be stubbing out side effects you
do not want—something handled easily by JenkinsPipelineUnit, at the
cost of running in an unrealistic environment.


For anyone interested in this general topic,

https://issues.jenkins-ci.org/browse/JENKINS-33925

has some longstanding discussion and ideas. (And, wow, 85 votes! Alas
there are no clear acceptance criteria for closing it.)

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3fDig6_-X-Pjnm1jRgv3RFZnC59ezcVpuSsjU4Wrw9sQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Kohsuke Kawaguchi
Administrator
Thanks for the pointer.

TBH, I haven't thought much at all about what that 3rd bullet actually means :-)   it was suggested by Johannes Schnatterer (and I don't know his email address, I hope he's reading this!) and it sounded like an area where this would be potentially relevant.

I can clearly see the value and trade-off of JenkinsPipelineUnit. I think it's a great project.

I suppose one path that Jenkinsfile Runner could take is not to stub out side effects. I think that's what Johannes meant by "integration" in "integration test" means. So that you can actually run some real stuff.

But I'm also intrigued at the thought of Jenkinsfile Runner running Jenkins in it, while stubbing out actual steps. That can certainly enable some additional testing scenarios.

The question I'd like to ask to people like Johannes, folks behind JenkinsPipelineUnit (once again I don't know their email addresse! even though I met them in Jenkins World!), and pipeline users in general is whether they find that valuable.



On Thu, Mar 1, 2018 at 3:00 PM Jesse Glick <[hidden email]> wrote:
For the third use case, what might be useful is an archetype or two analogous to

https://github.com/jenkinsci/archetypes/tree/master/scripted-pipeline/src/main/resources/archetype-resources
https://github.com/jenkinsci/archetypes/tree/master/global-shared-library/src/main/resources/archetype-resources

which use the Docker packaging and take care of all the boilerplate
needed to have a Maven module which, when “built”, runs the specified
`Jenkinsfile` or library against some test inputs in a well-controlled
environment, and presumably passes or fails according to some
conditions. (For example, Groovy validation scripts, akin to Maven
Invoker?) I think the hard part would be stubbing out side effects you
do not want—something handled easily by JenkinsPipelineUnit, at the
cost of running in an unrealistic environment.


For anyone interested in this general topic,

https://issues.jenkins-ci.org/browse/JENKINS-33925

has some longstanding discussion and ideas. (And, wow, 85 votes! Alas
there are no clear acceptance criteria for closing it.)

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3fDig6_-X-Pjnm1jRgv3RFZnC59ezcVpuSsjU4Wrw9sQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xM944n7TqMiz9FGF913j9ewPa6SR0wsTK%2B1_aPNadR%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Oleg Nenashev
Hi KK,

I have hacked something like that last summer when I wanted to have an end-to-end flow. Your implementation is much more ready for use, and +100 from me for the proposal. The CLI approach would be totally reasonable, especially for things like PipelineUnit where you have to bootstrap the job loading now.

My approach: In my case I have finally switched to another approach to local Pipeline development (short slidedeck from Jenkins World). I switched to a fully dockerized static-config "clone" of ci.jenkins.io setup, which was using FileSystem SCM plugin to bootstrap Pipelines and Groovy hooks to configure the instance.

Currently I am reworking my demo to support config-as-code plugin and other such goodies, so it would be more aligned with recent JEPs. OTOH my approach is far from being CLI-only, and it definitely does not address all Pipeline testing use-cases.


BR, Oleg

On Friday, March 2, 2018 at 3:36:02 AM UTC+1, Kohsuke Kawaguchi wrote:
Thanks for the pointer.

TBH, I haven't thought much at all about what that 3rd bullet actually means :-)   it was suggested by Johannes Schnatterer (and I don't know his email address, I hope he's reading this!) and it sounded like an area where this would be potentially relevant.

I can clearly see the value and trade-off of <a href="https://github.com/jenkinsci/JenkinsPipelineUnit" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2FJenkinsPipelineUnit\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE2d3JHwFoqI9-gfEJE6enTeAULtA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2FJenkinsPipelineUnit\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE2d3JHwFoqI9-gfEJE6enTeAULtA&#39;;return true;">JenkinsPipelineUnit. I think it's a great project.

I suppose one path that Jenkinsfile Runner could take is not to stub out side effects. I think that's what Johannes meant by "integration" in "integration test" means. So that you can actually run some real stuff.

But I'm also intrigued at the thought of Jenkinsfile Runner running Jenkins in it, while stubbing out actual steps. That can certainly enable some additional testing scenarios.

The question I'd like to ask to people like Johannes, folks behind JenkinsPipelineUnit (once again I don't know their email addresse! even though I met them in Jenkins World!), and pipeline users in general is whether they find that valuable.



On Thu, Mar 1, 2018 at 3:00 PM Jesse Glick <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="2b9D8STMAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jgl...@...> wrote:
For the third use case, what might be useful is an archetype or two analogous to

<a href="https://github.com/jenkinsci/archetypes/tree/master/scripted-pipeline/src/main/resources/archetype-resources" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Farchetypes%2Ftree%2Fmaster%2Fscripted-pipeline%2Fsrc%2Fmain%2Fresources%2Farchetype-resources\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGKM1_ofku0IUHRc0hLxWJoofApog&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Farchetypes%2Ftree%2Fmaster%2Fscripted-pipeline%2Fsrc%2Fmain%2Fresources%2Farchetype-resources\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGKM1_ofku0IUHRc0hLxWJoofApog&#39;;return true;">https://github.com/jenkinsci/archetypes/tree/master/scripted-pipeline/src/main/resources/archetype-resources
<a href="https://github.com/jenkinsci/archetypes/tree/master/global-shared-library/src/main/resources/archetype-resources" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Farchetypes%2Ftree%2Fmaster%2Fglobal-shared-library%2Fsrc%2Fmain%2Fresources%2Farchetype-resources\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3dAtjQ0_WgVanddCL7OR-GpRIpw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Farchetypes%2Ftree%2Fmaster%2Fglobal-shared-library%2Fsrc%2Fmain%2Fresources%2Farchetype-resources\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE3dAtjQ0_WgVanddCL7OR-GpRIpw&#39;;return true;">https://github.com/jenkinsci/archetypes/tree/master/global-shared-library/src/main/resources/archetype-resources

which use the Docker packaging and take care of all the boilerplate
needed to have a Maven module which, when “built”, runs the specified
`Jenkinsfile` or library against some test inputs in a well-controlled
environment, and presumably passes or fails according to some
conditions. (For example, Groovy validation scripts, akin to Maven
Invoker?) I think the hard part would be stubbing out side effects you
do not want—something handled easily by JenkinsPipelineUnit, at the
cost of running in an unrealistic environment.


For anyone interested in this general topic,

<a href="https://issues.jenkins-ci.org/browse/JENKINS-33925" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-33925\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGh2JWuilKAxgPdmK13IlGAqotbZA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fissues.jenkins-ci.org%2Fbrowse%2FJENKINS-33925\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGh2JWuilKAxgPdmK13IlGAqotbZA&#39;;return true;">https://issues.jenkins-ci.org/browse/JENKINS-33925

has some longstanding discussion and ideas. (And, wow, 85 votes! Alas
there are no clear acceptance criteria for closing it.)

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="2b9D8STMAQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3fDig6_-X-Pjnm1jRgv3RFZnC59ezcVpuSsjU4Wrw9sQ%40mail.gmail.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3fDig6_-X-Pjnm1jRgv3RFZnC59ezcVpuSsjU4Wrw9sQ%40mail.gmail.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3fDig6_-X-Pjnm1jRgv3RFZnC59ezcVpuSsjU4Wrw9sQ%40mail.gmail.com&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3fDig6_-X-Pjnm1jRgv3RFZnC59ezcVpuSsjU4Wrw9sQ%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/831181a6-c92e-4755-a5e3-5cf9524973e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Bill Dennis
In reply to this post by Kohsuke Kawaguchi
Hello Kohsuke -

I am a developer using Jenkins pipeline quite lot where I work.

We are using Jenkins pipelines in two scenarios:
  • For CI building and testing some of our internal components (what Jenkins is traditionally used for)
  • For running / orchestrating complex automation processes (so Jenkins is talking to some external systems using SOAP / REST etc) via tooling and even directly via REST using plugins.
I have mostly used JenkinsPipelineUnit for testing / validation of the pipelines and I have been looking into the direct / live approach that Oleg demonstrated (running Jenkins locally in Docker and getting the pipeline being developed direct from a host file system volume mount).

I think Jenkinsfile Runner would be really useful for developers who don't need or want the overhead of developing tests with JenkinsPipelineUnit. I have worked with some developers wanting to develop Jenkinsfiles for their CI process and the main problem is knowing if the Jenkinsfile will work when they commit it to the repo. They go round this loop of commit / fix running in the production Jenkins or using the Jenkins pipeline "replay" feature. It can be a painful process if you are not familiar with Jenkins pipeline and Groovy syntax!

I think some things to consider are:

- How does the Jenkins Runner replicate the agents / slaves identifiers on the target Jenkins?
- How to deal with tooling on the target Jenkins (custom tools, JDKs, Gradle, etc)?

I think the perfect Jenkinsfile Runner for me would provide:

- Somehow capture the plugins, tooling and agents on our production Jenkins
- Validate the Jenkinsfile pipeline syntax
- Validate the Jenkinsfile against the plugins and agents / tooling (fail if it refers to some tool or agent not configured for example).
- Run the Jenkinfile in some sort of "no-op" mode : what would it do if I ran it, without actually doing anything
- Actually run the Jenkinsfile locally so I can know it works completely before committing to source control.
- Run the Jenkinsfile on the target Jenkins master server using the resources of that server (so know it works on the server).

Hope that helps!

Bill Dennis


On Thursday, 1 March 2018 19:23:15 UTC, Kohsuke Kawaguchi wrote:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b475ecc2-2807-47c7-809f-5e6c1a51d2e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Kohsuke Kawaguchi
Administrator


On Fri, Mar 2, 2018 at 9:26 AM Bill Dennis <[hidden email]> wrote:
Hello Kohsuke -

I am a developer using Jenkins pipeline quite lot where I work.

We are using Jenkins pipelines in two scenarios:
  • For CI building and testing some of our internal components (what Jenkins is traditionally used for)
  • For running / orchestrating complex automation processes (so Jenkins is talking to some external systems using SOAP / REST etc) via tooling and even directly via REST using plugins.
I have mostly used JenkinsPipelineUnit for testing / validation of the pipelines and I have been looking into the direct / live approach that Oleg demonstrated (running Jenkins locally in Docker and getting the pipeline being developed direct from a host file system volume mount).

I think Jenkinsfile Runner would be really useful for developers who don't need or want the overhead of developing tests with JenkinsPipelineUnit. I have worked with some developers wanting to develop Jenkinsfiles for their CI process and the main problem is knowing if the Jenkinsfile will work when they commit it to the repo. They go round this loop of commit / fix running in the production Jenkins or using the Jenkins pipeline "replay" feature. It can be a painful process if you are not familiar with Jenkins pipeline and Groovy syntax!

This kind of context is really helpful. Thank you!

I think some things to consider are:

- How does the Jenkins Runner replicate the agents / slaves identifiers on the target Jenkins?
- How to deal with tooling on the target Jenkins (custom tools, JDKs, Gradle, etc)?

Right, I guess your point is that Jenkinsfile Runner should aim to run Jenkinsfile in much more realistic setup, and that doesn't stop at using real Jenkins and real Pipeline plugins, but it also needs to include other configurations of Jenkins. I think Jesse made a similar observation. I have a few thoughts:
  • Configuration-as-code could play a role here in terms of letting people define the configuration of Jenkins once and use it both in production and in setup like Jenkinsfile Runner
  • I'm a fan of making Jenkinsfile itself more portable. For example, if people are already in the mode of using docker images to run builds in, then more of the toolings would be packaged in there, and it should allow Jenkinsfile Runner to run your project in much the same way as your production Jenkins. I'm curious how much of this is already reality vs ideal that people are working toward.

I think the perfect Jenkinsfile Runner for me would provide:

- Somehow capture the plugins, tooling and agents on our production Jenkins
- Validate the Jenkinsfile pipeline syntax

I think this is already happening as a result of actually running the pipeline -- one of the virtue of actually using the real pipeline plugins to run!
 
- Validate the Jenkinsfile against the plugins and agents / tooling (fail if it refers to some tool or agent not configured for example).
- Run the Jenkinfile in some sort of "no-op" mode : what would it do if I ran it, without actually doing anything

This one is interesting. I assumed JenkinsPipelineUnit does this pretty well, though. Can you tell me more about this? I'm imagining you'd want to be able to selectively mock out some steps (e.g., when Jenkinsfile gets to sh "./deploy.sh" don't actually do it and pretend that it succeeded) but more details would be helpful.
 
- Actually run the Jenkinsfile locally so I can know it works completely before committing to source control.

Yeah, this was the first goal for me.
 
- Run the Jenkinsfile on the target Jenkins master server using the resources of that server (so know it works on the server).

This got me thinking that maybe all I needed was a Jenkins CLI command that behind the scene creates a temporary/hidden job on the target Jenkins master and run the Pipeline. IOW, keep the same development flow as Jenkinsfile Runner today, but don't run Jenkins locally, just do it on your actual Jenkins.
 

Hope that helps!

Bill Dennis


On Thursday, 1 March 2018 19:23:15 UTC, Kohsuke Kawaguchi wrote:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b475ecc2-2807-47c7-809f-5e6c1a51d2e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4yRV4iS-%3D%3D0ib_NWfux-g7N7URG56KekdhhHuFbguCLqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Jesse Glick-4
On Fri, Mar 2, 2018 at 12:56 PM, Kohsuke Kawaguchi <[hidden email]> wrote:
> well, though. Can you tell me more about this? I'm imagining you'd want to
> be able to selectively mock out some steps (e.g., when Jenkinsfile gets to
> sh "./deploy.sh" don't actually do it and pretend that it succeeded)

One suggestion alluded to in JENKINS-33925 was to have a globally
recognized “dry-run” flag (akin to `Main.isUnitTest` I suppose) that
could be checked from various features in core or plugins, so that for
example the `mail` step would know to just print out the mail it
_would_ have sent without actually contacting an SMTP server.

This would not help directly with your example above—since Jenkins
would have no way of knowing whether `deploy.sh` actually had any
externally visible effects, or was just a build command operating
locally in the workspace—but perhaps in dry-run mode a special
environment variable could be set for the whole build which would be
visible to external processes, so your own script could include
something like

if [ "$DRY_RUN" -eq true ]
then
    echo "Would be deploying to ${SERVER}:"
    ls -lR
    exit
fi
# else proceed

Not as flexible as the fine-grained mocking available (as I recall) in
JenkinsPipelineUnit, but perhaps sufficient for many use cases.

> This got me thinking that maybe all I needed was a Jenkins CLI command that
> behind the scene creates a temporary/hidden job on the target Jenkins master
> and run the Pipeline. IOW, keep the same development flow as Jenkinsfile
> Runner today, but don't run Jenkins locally, just do it on your actual
> Jenkins.

Already exists (though it uses your real job). See for example

https://jenkins.ci.cloudbees.com/cli/command/replay-pipeline

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr03Mg5r5i-XxMi8TZH3uUE7ER1mox76VuA2mX-OiKciZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

johannes
In reply to this post by Kohsuke Kawaguchi
I think Jenkinsfile Runner brings a lot of opportunities for pipeline developers. The most obvious ones to me are
  1. Pipeline development (Jenkinsfile)
  2. Shared library development

Pipeline development

Right now (as described by others in this thread) pipeline development is either a loop of committing / fixing pipelines on production Jenkins, using pipeline replay on production Jenkins or setting up a local instance manually.

With Jenkinsfile Runner we can get faster feedback without polluting our commit or Jenkins build history and don't have to set up a local instance manually.


Shared library development

Shared library development right now works much in the same as pipeline development, except that you have the library code and another (often production) Jenkinsfile to maintain, in order to try out (as opposed to automatically test) your Jenkinsfile.

For shared libraries, we thankfully already have JenkinsPipelineUnit, that makes it easier to implement some tests. However, (as also mentioned by others in this thread) this is unit testing only. It mocks most of our environment. Often, green unit tests mean nothing for productive use of our share library. I even gave up test-driven development for shared libraries, in favor of 90s try-and-error-style programming. Because most of the time when trying the library with green unit tests in production, it turns out that the real Jenkins environment has some restriction that is beyond the scope of JenkinsPieplineUnit (e.g. sandboxing).
Worst thing about the current state is that we don't have reliable regression tests. A change in shared library with green unit tests is far from convincing me that the library will continue to work in production.

With Jenkinsfile Runner we could write small Jenkinsfiles within the shared library repo's test folder and run them from the Jenkinsfile of the shared lib. Pretty much in the same way as we use Maven Invoker Plugin (as mentioned by Jesse) when developing maven plugins.

A first approach to shared library integration testing with Jenkinsfile Runner
My naive first approach was to build a Docker Image that contains Jenkinsfile Runner and all default plugins.

docker run -v~/src/it/myfunction:/workspace schnatterer/jenkinsfile-runner:1.0-SNAPSHOT-2.108 /workspace

runs the ~/foo/Jenkinsfile using Jenkinsfile Runner with all default plugins of Jenkins 2.108.

My idea was to eventually do the same in Jenkinsfile of the shared lib like so (not tested)
docker.image('schnatterer/jenkinsfile-runner:1.0-SNAPSHOT-2.108').inside {

    sh
'jenkinsfile-runner /app/jenkins /app/plugins src/it/myfunction'
}
or
sh 'docker run --rm -v $(pwd):$(pwd) src/it/myfunction'

It turned out that there a two major problems:
  1. There's no way to add non-default Jenkins plugins.
    My local test for cloudogu/ces-build-lib failed because there was no GitHub Groovy Libraries plugin.
    Here, my hope is that Configuration-as-code plugin might help automate loading plugins.
  2. There's still no way to load a "local" shared library from the same repo. So, we still would have to find a way to configure the shared library in our Jenkinsfile Runner.
    Loading local shared libraries has already been discussed here and there.

Once those issues are solved, we'll have a very basic way of automating integration tests for shared libraries by executing IT Jenkinsfiles from the shared libraries pipeline and failing the build if the IT fails.


Of course, this would be very basic testing. For more sophistiated testing we would want to

  • trigger the ITs from maven or gradle,
  • use asserts,
  • get the results as JUnit XML.
So, yes, we're not there yet. But we now have a foundation to build all this upon.

Thanks for that & best regards,

Johannes

Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi


Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/fcdcb7e4-f6ca-4ec5-bf7d-0c9ca32618ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Michael Neale-2
In reply to this post by Kohsuke Kawaguchi
Trying this out, looks like I am hitting JEP-200: 

https://jenkins.io/redirect/class-filter/

Need to dig in further (I thought I tried the same version of Jenkins as you). Anyone else seen this? 



java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; see https://jenkins.io/redirect/class-filter/
at hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:543)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
at com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:74)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
Caused: java.lang.RuntimeException: Failed to serialize hudson.model.Actionable#actions for class org.jenkinsci.plugins.workflow.job.WorkflowRun


On Friday, March 2, 2018 at 6:23:15 AM UTC+11, Kohsuke Kawaguchi wrote:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3836b845-5e9f-44d6-883d-10caf7e78832%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Bill Dennis
In reply to this post by Kohsuke Kawaguchi
Thanks Kohsuke, I tried to give some answers to your questions inline below, if I didn't mess up the reply..

Bill

On Friday, 2 March 2018 17:57:24 UTC, Kohsuke Kawaguchi wrote:


On Fri, Mar 2, 2018 at 9:26 AM Bill Dennis <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="-bsYM2z-AQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">bill....@...> wrote:
Hello Kohsuke -

I am a developer using Jenkins pipeline quite lot where I work.

We are using Jenkins pipelines in two scenarios:
  • For CI building and testing some of our internal components (what Jenkins is traditionally used for)
  • For running / orchestrating complex automation processes (so Jenkins is talking to some external systems using SOAP / REST etc) via tooling and even directly via REST using plugins.
I have mostly used JenkinsPipelineUnit for testing / validation of the pipelines and I have been looking into the direct / live approach that Oleg demonstrated (running Jenkins locally in Docker and getting the pipeline being developed direct from a host file system volume mount).

I think Jenkinsfile Runner would be really useful for developers who don't need or want the overhead of developing tests with JenkinsPipelineUnit. I have worked with some developers wanting to develop Jenkinsfiles for their CI process and the main problem is knowing if the Jenkinsfile will work when they commit it to the repo. They go round this loop of commit / fix running in the production Jenkins or using the Jenkins pipeline "replay" feature. It can be a painful process if you are not familiar with Jenkins pipeline and Groovy syntax!

This kind of context is really helpful. Thank you!
 
Happy to feedback. Thanks for Jenkins and pipeline as code, it helped me deliver some projects with Jenkins in a way that I thought would not be possible a few years ago.


I think some things to consider are:

- How does the Jenkins Runner replicate the agents / slaves identifiers on the target Jenkins?
- How to deal with tooling on the target Jenkins (custom tools, JDKs, Gradle, etc)?

Right, I guess your point is that Jenkinsfile Runner should aim to run Jenkinsfile in much more realistic setup, and that doesn't stop at using real Jenkins and real Pipeline plugins, but it also needs to include other configurations of Jenkins. I think Jesse made a similar observation. I have a few thoughts:
  • <a href="https://github.com/jenkinsci/configuration-as-code-plugin" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fconfiguration-as-code-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEBFSLRRiRNYGWqAZr6GdCRCYi73w&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fjenkinsci%2Fconfiguration-as-code-plugin\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEBFSLRRiRNYGWqAZr6GdCRCYi73w&#39;;return true;">Configuration-as-code could play a role here in terms of letting people define the configuration of Jenkins once and use it both in production and in setup like Jenkinsfile Runner
  • I'm a fan of making Jenkinsfile itself more portable. For example, if people are already in the mode of using docker images to run builds in, then more of the toolings would be packaged in there, and it should allow Jenkinsfile Runner to run your project in much the same way as your production Jenkins. I'm curious how much of this is already reality vs ideal that people are working toward.
Yes, all of this. I have often thought that we need something like declarative pipeline for the configuration of Jenkins as code instead of going into all those web config pages. Jenkins master as Docker container seems good. In our environment we are not currently using Docker but I have seen that that is the way to go. Getting a larger organisation to adopt the right technology and the associated costs of that is the challenge, so we remain using traditional Jenkins slaves and tooling methods. Hopefully Dockerised soon. We do use Jenkins Enterprise from CloudBees.


I think the perfect Jenkinsfile Runner for me would provide:

- Somehow capture the plugins, tooling and agents on our production Jenkins
- Validate the Jenkinsfile pipeline syntax

I think this is already happening as a result of actually running the pipeline -- one of the virtue of actually using the real pipeline plugins to run!
 
- Validate the Jenkinsfile against the plugins and agents / tooling (fail if it refers to some tool or agent not configured for example).
- Run the Jenkinfile in some sort of "no-op" mode : what would it do if I ran it, without actually doing anything

This one is interesting. I assumed JenkinsPipelineUnit does this pretty well, though. Can you tell me more about this? I'm imagining you'd want to be able to selectively mock out some steps (e.g., when Jenkinsfile gets to sh "./deploy.sh" don't actually do it and pretend that it succeeded) but more details would be helpful.

Yes, in JenkinsPipelineUnit I pretty much mock out everything like calls to tools. Because pipeline is based on Groovy I thought I could do some unit tests using Spock and Groovy for pipelines but then I discovered it was already done and shared as JenkinsPipelineUnit, so hat tip to Ozan there. So the Spock unit tests I write are confirming the execution of the tools is correct but not actually running them. I also write JenkinsPipelineUnit test code for my share library code as well confirming the behaviour, so actually all my use of special tooling is captured in libraries as DSL like constructs. A great feature of JenkinsPipelineUnit is that it can generate the execution callstack of the "mocked" pipeline run. These callstacks can be stored as files and JenkinsPipelineUnit tests can assert the execution callstack of a test run against a file committed as part of the tests. I do this for all my pipelines and share library units. So the callstacks actually capture the execution of tooling with commandline params etc and any time I change the pipeline code I can see what is changed by diffing the callstack file changes. Another thing you can do with this is run the pipeline jobs with different parameters in the tests (Spock parameterised tests) and by comparing the callstack files can see how the pipeline behaviour differs between these runs and assert the correct behaviour. All this without having to hit a real Jenkins server and wait for long running processes to complete! So this is all fine and you can write tests for the pipelines and check the use of tooling etc, but when you come to run the pipeline on the actual server, the tools or agents / slaves labels are not configured as expected for the fully tested pipeline. So this is where something like Jenkins Runner will be good to use. My tests are based on code methods in the project I have here: https://github.com/macg33zr/pipelineUnit
 
 
- Actually run the Jenkinsfile locally so I can know it works completely before committing to source control.

Yeah, this was the first goal for me.
 
- Run the Jenkinsfile on the target Jenkins master server using the resources of that server (so know it works on the server).

This got me thinking that maybe all I needed was a Jenkins CLI command that behind the scene creates a temporary/hidden job on the target Jenkins master and run the Pipeline. IOW, keep the same development flow as Jenkinsfile Runner today, but don't run Jenkins locally, just do it on your actual Jenkins.

Yes, this would be great, an anonymous job and just pull back the output and console log. A plugin for IntelliJ or whatever IDE using this would be even better :-) 
 

Hope that helps!

Bill Dennis


On Thursday, 1 March 2018 19:23:15 UTC, Kohsuke Kawaguchi wrote:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="-bsYM2z-AQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/jenkinsci-dev/b475ecc2-2807-47c7-809f-5e6c1a51d2e0%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/b475ecc2-2807-47c7-809f-5e6c1a51d2e0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/jenkinsci-dev/b475ecc2-2807-47c7-809f-5e6c1a51d2e0%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/jenkinsci-dev/b475ecc2-2807-47c7-809f-5e6c1a51d2e0%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c1ae5ba9-d54d-4c87-ad3d-d7b1ae004148%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Jesse Glick-4
In reply to this post by Michael Neale-2
On Tue, Mar 6, 2018 at 4:22 AM, Michael Neale <[hidden email]> wrote:
> java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; see https://jenkins.io/redirect/class-filter/

As suggested in that link, the JAR probably just needs a
`Jenkins-ClassFilter-Whitelisted: true` manifest header.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2dw%3DKoXwWyu-tYubOgN8YBg6dCZzNSsCnHFhcuyTkprA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Bill Dennis
In reply to this post by Michael Neale-2
I too am seeing the JEP-200 issue with these exceptions packaging to a Docker image and running with that using Docker for Windows:

java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.FileSystemSCM for security reasons; see https://jenkins.io/redirect/class-filter/
java
.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; see https://jenkins.io/redirect/class-filter/

I'd like to try out the Jenkinsfile Runner which looks like a great idea but I don't have time to figure this out right now (busy writing a plugin..).

--Bill


On Tuesday, 6 March 2018 09:22:53 UTC, Michael Neale wrote:
Trying this out, looks like I am hitting JEP-200: 

<a href="https://jenkins.io/redirect/class-filter/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.io%2Fredirect%2Fclass-filter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFMDliMtvDGzzpw3whb0KLiSIjE7A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.io%2Fredirect%2Fclass-filter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFMDliMtvDGzzpw3whb0KLiSIjE7A&#39;;return true;">https://jenkins.io/redirect/class-filter/

Need to dig in further (I thought I tried the same version of Jenkins as you). Anyone else seen this? 



java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; see <a href="https://jenkins.io/redirect/class-filter/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.io%2Fredirect%2Fclass-filter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFMDliMtvDGzzpw3whb0KLiSIjE7A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fjenkins.io%2Fredirect%2Fclass-filter%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFMDliMtvDGzzpw3whb0KLiSIjE7A&#39;;return true;">https://jenkins.io/redirect/class-filter/
at hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:543)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
at com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:74)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
Caused: java.lang.RuntimeException: Failed to serialize hudson.model.Actionable#actions for class org.jenkinsci.plugins.workflow.job.WorkflowRun


On Friday, March 2, 2018 at 6:23:15 AM UTC+11, Kohsuke Kawaguchi wrote:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/da0e3018-9206-43a3-b814-4a65a73d5c17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Oleg Nenashev
Yeah, the entire library needs to me whitelisted (or packaged as Jenkins module).
It's actually a quick-win to get it fixed as long as it is a development tool.

BR, Oleg


On Tue, Mar 6, 2018 at 5:00 PM, Bill Dennis <[hidden email]> wrote:
I too am seeing the JEP-200 issue with these exceptions packaging to a Docker image and running with that using Docker for Windows:

java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.FileSystemSCM for security reasons; see https://jenkins.io/redirect/class-filter/
java
.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; see https://jenkins.io/redirect/class-filter/

I'd like to try out the Jenkinsfile Runner which looks like a great idea but I don't have time to figure this out right now (busy writing a plugin..).

--Bill


On Tuesday, 6 March 2018 09:22:53 UTC, Michael Neale wrote:
Trying this out, looks like I am hitting JEP-200: 


Need to dig in further (I thought I tried the same version of Jenkins as you). Anyone else seen this? 



java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; see https://jenkins.io/redirect/class-filter/
at hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:543)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
at com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:74)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
Caused: java.lang.RuntimeException: Failed to serialize hudson.model.Actionable#actions for class org.jenkinsci.plugins.workflow.job.WorkflowRun


On Friday, March 2, 2018 at 6:23:15 AM UTC+11, Kohsuke Kawaguchi wrote:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/gjz3CDhi-kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/da0e3018-9206-43a3-b814-4a65a73d5c17%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLC6%3DyuTyakmF_cMryuJNa68bLLQO%3DrrR9VU%3D5gmAmfksg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

johannes
In reply to this post by Kohsuke Kawaguchi
Same exception here: java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons;

I created an issue with full stacktrace.
Jesse or Oleg, maybe you could elaborate there how we could fix this.
Which Jar needs the manifest, which library needs to be whitelisted and how can we achieve this?

Cheers,
Johannes

Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/aef469a7-5b3f-4fb1-9ccf-12a11a3d1be5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Oleg Nenashev
I will create a pull request, stay tuned

On Tuesday, March 6, 2018 at 7:32:21 PM UTC+1, [hidden email] wrote:
Same exception here: java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons;

I created an <a href="https://github.com/kohsuke/jenkinsfile-runner/issues/7" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkohsuke%2Fjenkinsfile-runner%2Fissues%2F7\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSePDDB4nAhUJ9b2AOU9dIdu7PJg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fkohsuke%2Fjenkinsfile-runner%2Fissues%2F7\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGSePDDB4nAhUJ9b2AOU9dIdu7PJg&#39;;return true;">issue with full stacktrace.
Jesse or Oleg, maybe you could elaborate there how we could fix this.
Which Jar needs the manifest, which library needs to be whitelisted and how can we achieve this?

Cheers,
Johannes

Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8ad1c473-5292-4a38-ab6b-ab78c4371092%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Oleg Nenashev

On Tue, Mar 6, 2018 at 8:13 PM, Oleg Nenashev <[hidden email]> wrote:
I will create a pull request, stay tuned

On Tuesday, March 6, 2018 at 7:32:21 PM UTC+1, [hidden email] wrote:
Same exception here: java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons;

I created an issue with full stacktrace.
Jesse or Oleg, maybe you could elaborate there how we could fix this.
Which Jar needs the manifest, which library needs to be whitelisted and how can we achieve this?

Cheers,
Johannes

Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/gjz3CDhi-kk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8ad1c473-5292-4a38-ab6b-ab78c4371092%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLBA%2B0k%2BXsPW57nJExWuEpao6dEs_h7oSVJ%3DHG5qQyWSRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Kohsuke Kawaguchi
Administrator
In reply to this post by Jesse Glick-4
Yeah, there are many possible ways to go about something like this, including what you described. That's why I'm trying to hear from Bill what his world looks like. I can use some concrete data points like that.

On Fri, Mar 2, 2018 at 11:08 AM Jesse Glick <[hidden email]> wrote:
On Fri, Mar 2, 2018 at 12:56 PM, Kohsuke Kawaguchi <[hidden email]> wrote:
> well, though. Can you tell me more about this? I'm imagining you'd want to
> be able to selectively mock out some steps (e.g., when Jenkinsfile gets to
> sh "./deploy.sh" don't actually do it and pretend that it succeeded)

One suggestion alluded to in JENKINS-33925 was to have a globally
recognized “dry-run” flag (akin to `Main.isUnitTest` I suppose) that
could be checked from various features in core or plugins, so that for
example the `mail` step would know to just print out the mail it
_would_ have sent without actually contacting an SMTP server.

This would not help directly with your example above—since Jenkins
would have no way of knowing whether `deploy.sh` actually had any
externally visible effects, or was just a build command operating
locally in the workspace—but perhaps in dry-run mode a special
environment variable could be set for the whole build which would be
visible to external processes, so your own script could include
something like

if [ "$DRY_RUN" -eq true ]
then
    echo "Would be deploying to ${SERVER}:"
    ls -lR
    exit
fi
# else proceed

Not as flexible as the fine-grained mocking available (as I recall) in
JenkinsPipelineUnit, but perhaps sufficient for many use cases.

> This got me thinking that maybe all I needed was a Jenkins CLI command that
> behind the scene creates a temporary/hidden job on the target Jenkins master
> and run the Pipeline. IOW, keep the same development flow as Jenkinsfile
> Runner today, but don't run Jenkins locally, just do it on your actual
> Jenkins.

Already exists (though it uses your real job). See for example

https://jenkins.ci.cloudbees.com/cli/command/replay-pipeline

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr03Mg5r5i-XxMi8TZH3uUE7ER1mox76VuA2mX-OiKciZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xBAfGRMXX8yiryE%2B3zv5cdKAefa3L53jb6egjRCBZ14w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Kohsuke Kawaguchi
Administrator
In reply to this post by johannes


On Sun, Mar 4, 2018 at 8:13 AM <[hidden email]> wrote:
I think Jenkinsfile Runner brings a lot of opportunities for pipeline developers. The most obvious ones to me are
  1. Pipeline development (Jenkinsfile)
  2. Shared library development

Pipeline development

Right now (as described by others in this thread) pipeline development is either a loop of committing / fixing pipelines on production Jenkins, using pipeline replay on production Jenkins or setting up a local instance manually.

With Jenkinsfile Runner we can get faster feedback without polluting our commit or Jenkins build history and don't have to set up a local instance manually.

Right. I think we all get this basic picture. Details are where things get interesting!

Shared library development

Shared library development right now works much in the same as pipeline development, except that you have the library code and another (often production) Jenkinsfile to maintain, in order to try out (as opposed to automatically test) your Jenkinsfile.

For shared libraries, we thankfully already have JenkinsPipelineUnit, that makes it easier to implement some tests. However, (as also mentioned by others in this thread) this is unit testing only. It mocks most of our environment. Often, green unit tests mean nothing for productive use of our share library. I even gave up test-driven development for shared libraries, in favor of 90s try-and-error-style programming. Because most of the time when trying the library with green unit tests in production, it turns out that the real Jenkins environment has some restriction that is beyond the scope of JenkinsPieplineUnit (e.g. sandboxing). 
Worst thing about the current state is that we don't have reliable regression tests. A change in shared library with green unit tests is far from convincing me that the library will continue to work in production.

With Jenkinsfile Runner we could write small Jenkinsfiles within the shared library repo's test folder and run them from the Jenkinsfile of the shared lib. Pretty much in the same way as we use Maven Invoker Plugin (as mentioned by Jesse) when developing maven plugins.

OK, thank you, this is really helpful. I think maven invoker plugin analogy is a great one for somebody like me. So from this perspective, mocking isn't really high on the priority. 
 

A first approach to shared library integration testing with Jenkinsfile Runner
My naive first approach was to build a Docker Image that contains Jenkinsfile Runner and all default plugins.

docker run -v~/src/it/myfunction:/workspace schnatterer/jenkinsfile-runner:1.0-SNAPSHOT-2.108 /workspace

runs the ~/foo/Jenkinsfile using Jenkinsfile Runner with all default plugins of Jenkins 2.108.

My idea was to eventually do the same in Jenkinsfile of the shared lib like so (not tested)
docker.image('schnatterer/jenkinsfile-runner:1.0-SNAPSHOT-2.108').inside {

    sh
'jenkinsfile-runner /app/jenkins /app/plugins src/it/myfunction'
}
or
sh 'docker run --rm -v $(pwd):$(pwd) src/it/myfunction'

So if this is the intended use case, then I have another idea. Instead of running Jenkinsfile in this CLI and try to emulate your Jenkins instance as closely as possible (in terms of configuration), we could just run Jenkinsfile in the current Jenkins, in a place that nobody else can see. 

For example, packaged as CLI, you'd run it like:

   $ java -jar jenkins-cli.jar -s https://jenkins.example.com/ run-pipeline ./src/it/myfunction

Or from within Jenkinsfile, could be something like:

  pipeline.sharedlibrary.test './src/it/myfunction'

... and this would completely bypass the challenge of trying to replicate the Jenkins configuration.

 
It turned out that there a two major problems:
  1. There's no way to add non-default Jenkins plugins.
    My local test for cloudogu/ces-build-lib failed because there was no GitHub Groovy Libraries plugin.
    Here, my hope is that Configuration-as-code plugin might help automate loading plugins.
Yeah, I'm really looking forward for CaC project to fill this gap, and I know they are working on it. 
  1. There's still no way to load a "local" shared library from the same repo. So, we still would have to find a way to configure the shared library in our Jenkinsfile Runner.
    Loading local shared libraries has already been discussed here and there.
Good point.
 

Once those issues are solved, we'll have a very basic way of automating integration tests for shared libraries by executing IT Jenkinsfiles from the shared libraries pipeline and failing the build if the IT fails.


That'd be really cool, isn't it!? 

Of course, this would be very basic testing. For more sophistiated testing we would want to

  • trigger the ITs from maven or gradle,
  • use asserts,
  • get the results as JUnit XML.
So, yes, we're not there yet. But we now have a foundation to build all this upon.

asserts would already work, right? It seems like we can do that relatively easily on its own.

But with that aside, I think I understand the picture in your head. You are really approaching it like Maven plugin development. Indeed this would help illustrate relative strength of both JenkinsPipelineUnit and "integration tests"
 

Thanks for that & best regards,

Johannes


Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi


Am Donnerstag, 1. März 2018 20:23:15 UTC+1 schrieb Kohsuke Kawaguchi:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/fcdcb7e4-f6ca-4ec5-bf7d-0c9ca32618ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4wqSeMyg9sY0G1xC9pEtgGqDvU-w42VrLgPzYRYNKavZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: POTD: Jenkinsfile Runner

Kohsuke Kawaguchi
Administrator
In reply to this post by Michael Neale-2
Oleg gave us the fix, which I merged to the master just now. I think that'll fix the problem.

On Tue, Mar 6, 2018 at 1:22 AM Michael Neale <[hidden email]> wrote:
Trying this out, looks like I am hitting JEP-200: 


Need to dig in further (I thought I tried the same version of Jenkins as you). Anyone else seen this? 



java.lang.UnsupportedOperationException: Refusing to marshal io.jenkins.jenkinsfile.runner.SetJenkinsfileLocation for security reasons; see https://jenkins.io/redirect/class-filter/
at hudson.util.XStream2$BlacklistedTypesConverter.marshal(XStream2.java:543)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
at com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:74)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:265)
at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:252)
Caused: java.lang.RuntimeException: Failed to serialize hudson.model.Actionable#actions for class org.jenkinsci.plugins.workflow.job.WorkflowRun


On Friday, March 2, 2018 at 6:23:15 AM UTC+11, Kohsuke Kawaguchi wrote:
Jenkinsfile Runner is an experiment to package Jenkins pipeline execution as a command line tool. The intend use cases include:
  • Use Jenkins in Function-as-a-Service context
  • Assist editing Jenkinsfile locally
  • Integration test shared libraries
Over the past year, I've done some deep-dive 1:1 conversations with some Jenkins users and I felt something like this might move the needle for them in an important way.

I'd love to hear any reactions on your side. Could something like this be important for you, does it miss any key points for you? If you mentally picture a perfect version of this, what would that do, and how would you use?

Let me know!

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3836b845-5e9f-44d6-883d-10caf7e78832%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xs-Y3WQ365CXpeORMyo%2BL-uMScPof2FqMCzv%3DxWx7eqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
12