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

Build step returns null if propagate set to true

      When running a build from another job and setting the propagate property to true, if the downstream job fails, the returned value is null.

      For example, if I want to copy the artifacts and I use returnValue.getNumber(), I get the error message:
      java.lang.NullPointerException: Cannot invoke method getNumber() on null object

          [JENKINS-48475] Build step returns null if propagate set to true

          vadim sluzky added a comment -

          Got it. I set propagate to false and then analyzed result field. Thank you for quick help, Andrew!

          vadim sluzky added a comment - Got it. I set propagate to false and then analyzed result field. Thank you for quick help, Andrew!

          vadim sluzky added a comment - - edited

          There is still a problem with that implementation.

          If propagate is set to false, all the corresponding tests are displayed in GREEN

          Is it possible to let the upstream  job know about failures?

          Are there any problems with returning real non-null result if wait is true?

           What is the logic behind using 'propagate' field to whether returning result?

          I strongly believe it should be returned or not based on 'wait' parameter and this is a valid non-minor defect that does not have a workaround and needs to be fixed

           

          vadim sluzky added a comment - - edited There is still a problem with that implementation. If propagate is set to false, all the corresponding tests are displayed in GREEN Is it possible to let the upstream  job know about failures? Are there any problems with returning real non-null result if wait is true?  What is the logic behind using 'propagate' field to whether returning result? I strongly believe it should be returned or not based on 'wait' parameter and this is a valid non-minor defect that does not have a workaround and needs to be fixed  

          vadim sluzky added a comment -

          I can not agree with resolution "Resolved" because it is "not a defect".

          If a build is not SUCCESSFUL, there is a need to have it results like a link to BUILD_URL.

          Consider the following use case:

              Run Tests as Jenkins jobs called from pipeline

              Provide links to jobs that failed

          The suggested solution is to set propagate to false that results in displaying all builds/tests as SUCCESSFUL - it's not acceptable.

          IMO, whether or not to return results of execution should depend on wait parameter. If wait is true, results should be available and should be returned. If wait is false - build is only launched without waiting to its completion - then result is not available.

          That should not be related to 'propagate' 

          vadim sluzky added a comment - I can not agree with resolution "Resolved" because it is "not a defect". If a build is not SUCCESSFUL, there is a need to have it results like a link to BUILD_URL. Consider the following use case:     Run Tests as Jenkins jobs called from pipeline     Provide links to jobs that failed The suggested solution is to set propagate to false that results in displaying all builds/tests as SUCCESSFUL - it's not acceptable. IMO, whether or not to return results of execution should depend on wait parameter. If wait is true, results should be available and should be returned. If wait is false - build is only launched without waiting to its completion - then result is not available. That should not be related to 'propagate' 

          Andrew Bayer added a comment -

          So this is definitely a confusing setting, no question. The problem here is that propagate really just means "if the downstream build fails, this step fails too". That directly results in returning null - a failed Pipeline step can't return anything. I'll leave this open in case an alternative approach comes to mind, but I don't think there's a way to achieve what you want.

          Andrew Bayer added a comment - So this is definitely a confusing setting, no question. The problem here is that propagate really just means "if the downstream build fails, this step fails too". That directly results in returning null - a failed Pipeline step can't return anything. I'll leave this open in case an alternative approach comes to mind, but I don't think there's a way to achieve what you want.

          vadim sluzky added a comment -

          An alternative might be parsing upstream's job output, but this looks like too weird workaround. I surmise that result's data is available if wait is true and can be returned - please correct me if I'm wrong 

          vadim sluzky added a comment - An alternative might be parsing upstream's job output, but this looks like too weird workaround. I surmise that result's data is available if wait is true and can be returned - please correct me if I'm wrong 

          Andrew Bayer added a comment -

          You can definitely act on the downstream run's result - def foo = build ...; if (foo.result != "SUCCESS") ..., e.g. But the build step itself will still be marked as successful.

          Andrew Bayer added a comment - You can definitely act on the downstream run's result - def foo = build ...; if (foo.result != "SUCCESS") ... , e.g. But the build step itself will still be marked as successful.

          vadim sluzky added a comment -

          Yes, I tried that way and it's not acceptable in my case because build steps are marked as passed

          vadim sluzky added a comment - Yes, I tried that way and it's not acceptable in my case because build steps are marked as passed

          Andrew Bayer added a comment -

          Sorry to hear that - then you are stuck, since as I said, at least in current Pipeline design, a step can't both fail and return something.

          Andrew Bayer added a comment - Sorry to hear that - then you are stuck, since as I said, at least in current Pipeline design, a step can't both fail and return something.

          I am sure vadim figured it out already but heres what we do just for anybody else. We also need some info on failing downstreams, you can get it from the object thrown by the build step, for example the build number:

           

          Its not the best thing ever but we just use it as a workaround for a different blue ocean problem that will hopefully be fixed soon:

          try {
           build(...)
          }
          catch (Exception e) {
           e.toString().split(" ").each {
                if(it.contains("#")) {
                  def buildNumber = it.substring(1)
          ...
                }
              }
          }
          

           

          Werner Wessely added a comment - I am sure vadim figured it out already but heres what we do just for anybody else. We also need some info on failing downstreams, you can get it from the object thrown by the build step, for example the build number:   Its not the best thing ever but we just use it as a workaround for a different blue ocean problem that will hopefully be fixed soon: try { build(...) } catch (Exception e) { e.toString().split( " " ).each { if (it.contains( "#" )) { def buildNumber = it.substring(1) ... } } }  

          Yacov Cohen added a comment -

          I'm in the same situation. I have a stage in the beginning of the pipeline that should trigger a job and get the build results in the end of the build.

          There is any way to do that? I tried to run it parallel with 'wait: true' but there is no option to use when condition for the internal stages.

          Yacov Cohen added a comment - I'm in the same situation. I have a stage in the beginning of the pipeline that should trigger a job and get the build results in the end of the build. There is any way to do that? I tried to run it parallel with 'wait: true' but there is no option to use when condition for the internal stages.

            Unassigned Unassigned
            gils Gil Shinar
            Votes:
            3 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated: