On Friday, October 21, 2016 at 6:11:28 PM UTC+1, Baptiste Mathus wrote: > > One thing to understand is that your pipeline is actually always to be run > from/on the master. Each "instruction" if actually sent from the master the > requested node, then kind of checkpointed before going further. > > So, when you're using a pipeline, it's aware of that. When you're using > directly groovy, you end up running on the master. > > That's one the reasons you should prefer using the pipeline-utility-steps > plugin for that matter, and in general keep your pipeline code as simple as > possible. > > HTH > > Hi Baptiste,
thanks, I'd pretty much worked that out but it's good to have it clarified. Having gone through various hassles relating to Groovy in the pipeline I think I might propose a "Gotchas" section for the documentation, pointing out the pitfalls. It's confusing when you're starting out and some things work while others don't, and then you google for answers to questions and don't realize that the answers you've found relate to system.groovy rather than pipeline.groovy. A simple "this is the issue, this works, this doesn't (or cannot be guaranteed to), beware the difference with system.groovy when looking for answers to questions" page would have saved me an incredible amount of time. Also, I wonder if there would be a way to implement a pipeline step that let you run groovy on the slave, passing parameters to it. Doing stuff through shell scripts, even if you're basically using them to call scripts in other languages, is rather messy. -- 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/689d5a38-d6c3-4aa7-8a78-b7d0c03dba4f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
