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

Pipeline "currentBuild" should expose build causes

    Details

    • Similar Issues:
    • Released As:
      workflow-support 2.22

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            bitwiseman Liam Newman added a comment - - edited

            Implementation should be similar to JENKINS-37366.

            Show
            bitwiseman Liam Newman added a comment - - edited Implementation should be similar to JENKINS-37366 .
            Show
            mpavlov mpavlov added a comment - Please review: https://github.com/jenkinsci/workflow-support-plugin/pull/36
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            franky4ro 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)

            Show
            franky4ro 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)
            Hide
            lushdog Matt Moore added a comment -

            +1 on Dan Albu'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..."

            Show
            lushdog Matt Moore added a comment - +1 on Dan Albu '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..."
            Hide
            jglick Jesse Glick added a comment -

            Filed a sketch.

            Show
            jglick Jesse Glick added a comment - Filed a sketch.
            Hide
            dnusbaum 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)
            Show
            dnusbaum 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)

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: