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

Pipeline "currentBuild" should expose build causes

    XMLWordPrintable

Details

    • 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

            bitwiseman Liam Newman created issue -
            bitwiseman Liam Newman added a comment - - edited

            Implementation should be similar to JENKINS-37366.

            bitwiseman Liam Newman added a comment - - edited Implementation should be similar to JENKINS-37366 .
            bitwiseman Liam Newman made changes -
            Field Original Value New Value
            Link This issue relates to JENKINS-37366 [ JENKINS-37366 ]
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-31576 [ JENKINS-31576 ]
            jglick Jesse Glick made changes -
            Component/s pipeline [ 21692 ]
            mpavlov mpavlov added a comment - Please review: https://github.com/jenkinsci/workflow-support-plugin/pull/36
            jamesdumay James Dumay made changes -
            Labels cloudbees-internal-pipeline
            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.

            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.
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal CD-124 (Web Link)" [ 18962 ]
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal CD-177 (Web Link)" [ 19111 ]
            vivek Vivek Pandey made changes -
            Assignee Sam Van Oort [ svanoort ]
            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)

            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)
            lushdog 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..."

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

            Filed a sketch.

            jglick Jesse Glick added a comment - Filed a sketch.
            jglick Jesse Glick made changes -
            Remote Link This issue links to "workflow-basic-steps 71 (Web Link)" [ 21831 ]
            jglick Jesse Glick made changes -
            Assignee Sam Van Oort [ svanoort ] Jesse Glick [ jglick ]
            jglick Jesse Glick made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            dnusbaum Devin Nusbaum made changes -
            Link This issue relates to JENKINS-54323 [ JENKINS-54323 ]
            dnusbaum Devin Nusbaum made changes -
            Link This issue is duplicated by JENKINS-54227 [ JENKINS-54227 ]
            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)
            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)
            dnusbaum Devin Nusbaum made changes -
            Released As workflow-support 2.22
            Assignee Jesse Glick [ jglick ] mike cirioli [ mikecirioli ]
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            aarondmarasco_vsi Aaron D. Marasco made changes -
            Link This issue is related to JENKINS-43754 [ JENKINS-43754 ]
            dnusbaum Devin Nusbaum made changes -
            Link This issue is duplicated by JENKINS-55758 [ JENKINS-55758 ]
            jglick Jesse Glick made changes -
            Link This issue is blocking JENKINS-53193 [ JENKINS-53193 ]

            People

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

              Dates

                Created:
                Updated:
                Resolved: