Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-41272

Pipeline "currentBuild" should expose build causes

    • workflow-support 2.22

      Pipeline currentBuild should expose the build causes.

      Currently, users have to resort to rawBuild to get this information
      http://stackoverflow.com/questions/33587927/how-to-get-cause-in-workflow

          [JENKINS-41272] Pipeline "currentBuild" should expose build causes

          Liam Newman added a comment - - edited

          Implementation should be similar to JENKINS-37366.

          Liam Newman added a comment - - edited Implementation should be similar to JENKINS-37366 .

          mpavlov added a comment -

          mpavlov added a comment - Please review: https://github.com/jenkinsci/workflow-support-plugin/pull/36

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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.

          Dan Albu added a comment -

          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)

          Dan Albu added a comment - 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)

          Matt Moore added a comment -

          +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..."

          Matt Moore added a comment - +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..."

          Jesse Glick added a comment -

          Filed a sketch.

          Jesse Glick added a comment - Filed a sketch.

          Devin Nusbaum added a comment -

          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)

          Devin Nusbaum added a comment - 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)

            mikecirioli mike cirioli
            bitwiseman Liam Newman
            Votes:
            39 Vote for this issue
            Watchers:
            44 Start watching this issue

              Created:
              Updated:
              Resolved: