Implementation should be similar to JENKINS-37366.

Please review: https://github.com/jenkinsci/workflow-support-plugin/pull/36

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.

Hey guys, any update on this?

We would really appreciate if we can get the cause of the pipeline trigger via the currentBuild:

e.g:

currentBuild.TriggerCause -> returns String (Started by user John Doe)

+1 on franky4ro's comment.  This feature would be super useful in cases like mine where we want one Multibranch Pipeline project to run our CI but we want some phases run on commit and some on a schedule.  Without checking the Trigger there is no way to do something like "Build when trigger is commit, deploy when trigger is timer..."

Filed a sketch.

This functionality was added in version 2.22 of the Pipeline Supporting APIs plugin. See JENKINS-54227 for more information. In summary, the following methods that return JSON objects have been added:

• currentBuild.getBuildCauses()
• currentBuild.getBuildCauses(String superClassName)