Liam Newman added a comment - 2017-01-21 00:01 - edited Implementation should be similar to JENKINS-37366 .

mpavlov added a comment - 2017-06-15 11:27 Please review: https://github.com/jenkinsci/workflow-support-plugin/pull/36

Jesse Glick added a comment - 2017-11-29 11:06 I suspect we will need to design a deeper fix that more generally solves the issue of exposing Jenkins model API data to Pipeline builds in a stable and secure fashion. The best candidate would be to reuse Stapler’s export  facility, so that for example a Cause would be represented according to its existing @Exported properties. One style would be to return GroovyObject instances with a special whitelist allowing them to be dynamically inspected for arbitrarily nested properties. Not too hard to do, and would work nicely with the current workflow-cps execution engine, but would become a headache if we have a different engine, as is being discussed. Another style would be to export to some depth and return the result as a flat data structure like a Map (using JSON is problematic with script security, due to the excessively weird design of json-lib ). But this is inflexible and inefficient in general, so it would be better to take a required tree parameter and return the selected data that way. This would also make it straightforward to pretest queries using existing REST APIs from out of process. But that just leads to the more general option of introducing a step which allows you to specify a model object relative URL and a tree and returns the corresponding exported data, using the authentication associated with the build, simulating a REST call without actually needing to make an HTTP connection. Then RunWrapper would merely need to expose a url property, and we could move away from doing too much with this global variable (or even deprecate it in favor of a simple environment variable), which would be even better for alternate execution engines.