On Fri, Mar 2, 2018 at 12:56 PM, Kohsuke Kawaguchi <k...@kohsuke.org> 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 ]
    echo "Would be deploying to ${SERVER}:"
    ls -lR
# 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


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 jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to