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,
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!
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
> 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 view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.