• Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • pipeline
    • None

      Currently the build step will either return Result.SUCCESS, or fail. It should rather return some POJO with whitelisted methods to get the result, get a number/URL, set a description, and so on.

      The obvious fix is to just return the Run. The problem is how to allow setDescription. This checks UPDATE, so as a rule it should be allowed only when running with a defined authentication. But flows usually do not run with any authentication, in which case this would fail—even though we should arguably always allow it on a build we triggered ourselves. On the other hand, it is desirable going forward to ask for authentication on projects, in which case you would need some permission on the downstream project to trigger its build anyway.

      Compatibility: the current return value is useless and so no one would be relying on it, but some scripts may be relying on a non-stable downstream build failing the flow, so it should be an option to allow the flow to proceed even if the downstream build is not stable (in which case the new return value takes effect).

          [JENKINS-25851] Richer return value for build step

          Jesse Glick created issue -

          Jesse Glick added a comment -

          A caveat when returning Run is that this is not serializable, and so may not be used as the return value of a step—unless RunPickle is created to save it safely.

          Jesse Glick added a comment - A caveat when returning Run is that this is not serializable, and so may not be used as the return value of a step—unless RunPickle is created to save it safely.
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-26123 [ JENKINS-26123 ]

          Jesse Glick added a comment -

          Cf. this discussion about being able to access the Run for this build.

          Jesse Glick added a comment - Cf. this discussion about being able to access the Run for this build.
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-26276 [ JENKINS-26276 ]

          Jesse Glick added a comment -

          Should also be able to access build variables (for an AbstractBuild) as a Map<String,String>.

          Jesse Glick added a comment - Should also be able to access build variables (for an AbstractBuild ) as a Map<String,String> .
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-26834 [ JENKINS-26834 ]
          Jesse Glick made changes -
          Link Original: This issue is related to JENKINS-26276 [ JENKINS-26276 ]

          Jesse Glick added a comment -

          JENKINS-26670 would be needed for setDescription (a special exemption could be made for the current build).

          Jesse Glick added a comment - JENKINS-26670 would be needed for setDescription (a special exemption could be made for the current build).
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-26670 [ JENKINS-26670 ]

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            4 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated:
              Resolved: