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

build job propagate true propagates FAIL when state is UNSTABLE

    XMLWordPrintable

Details

    • pipeline-build-step 2.10, workflow-cps 2.77

    Description

      Im using a build command in a parallel step and, when the job finishes with UNSTABLE it stops execution because main job (which executes build) becomes in a FAILURE status.

      Attachments

        Issue Links

          Activity

            pjung Philipp Jung added a comment -

            I can reproduce this again on both our Jenkins instances: with Build-Step 2.12 and Pipeline Groovy 2.80.

            Here is a minimal example: The second part of the "unstable -> success"  stage is never executed.

            // Parent Job
            node(){
                def stage_map = [:]
                stage_map['success'] = trigger('SUCCESS')
                stage_map['unstable -> success']= {trigger('UNSTABLE').call(); trigger('SUCCESS').call()} // The second SUCCESS step is never triggered
                
                parallel(stage_map)
            }
            
            def trigger(status){
                return {
                    def result = build job:
                        'test_child',
                        parameters: [
                                string(name: 'status', value: status)
                            ]
                }
            }
            
            // Child Job
            node(){
                  properties([
                    parameters([string(name: 'status', defaultValue: 'SUCCESS')])
                ]) 
                currentBuild.result = params.status
            }
            
            pjung Philipp Jung added a comment - I can reproduce this again on both our Jenkins instances: with Build-Step 2.12 and Pipeline Groovy 2.80. Here is a minimal example: The second part of the "unstable -> success"  stage is never executed. // Parent Job node(){ def stage_map = [:] stage_map[ 'success' ] = trigger( 'SUCCESS' ) stage_map[ 'unstable -> success' ]= {trigger( 'UNSTABLE' ).call(); trigger( 'SUCCESS' ).call()} // The second SUCCESS step is never triggered parallel(stage_map) } def trigger(status){ return { def result = build job: 'test_child' , parameters: [ string(name: 'status' , value: status) ] } } // Child Job node(){ properties([ parameters([string(name: 'status' , defaultValue: 'SUCCESS' )]) ]) currentBuild.result = params.status }
            jglick Jesse Glick added a comment -

            The second part of the "unstable -> success" stage is never executed.

            As designed. Your parent job should terminate at that point with an UNSTABLE status. This change does not make the build step complete normally; it just makes the exception thrown indicate to the Pipeline machinery that (if uncaught) the build should have the indicated status. If you do not want that, then use propagate: false as before.

            jglick Jesse Glick added a comment - The second part of the "unstable -> success" stage is never executed. As designed. Your parent job should terminate at that point with an UNSTABLE status. This change does not make the build step complete normally; it just makes the exception thrown indicate to the Pipeline machinery that (if uncaught) the build should have the indicated status. If you do not want that, then use propagate: false as before.
            pjung Philipp Jung added a comment -

            Thanks for clearing that up.

            pjung Philipp Jung added a comment - Thanks for clearing that up.
            jayspang Jay Spang added a comment - - edited

            This fix introduced a new bug in my pipeline.

            The `build` step used to throw hudson.AbortException, but was changed to org.jenkinsci.plugins.workflow.steps.FlowInterruptedException.

            The problem: AbortException had a "message" which contained the job name/number, along with its status. We used this in our error handling to include context to the error. FlowInterruptedException contains no message, so our error handling fails. Unless I'm missing something, it contains almost no information on what actually failed.

            Should this bug be re-opened, or a new bug opened to pass FlowInterruptedException some contextual information?

            EDIT: Here's a code snippet to help explain:

            try{
                def results = build job: 'fooJob'
                def job_number = results.getNumber()
            } catch (e) {
                // AbortMessage included a message along the lines of...
                // "fooJob #13 completed with status FAILURE (propagate: false to ignore)"
                // We used this message to add context to the error
                def msg = e.getMessage() // Sadly, this is null for FlowInterruptedException
            }
            
            jayspang Jay Spang added a comment - - edited This fix introduced a new bug in my pipeline. The `build` step used to throw hudson.AbortException , but was changed to org.jenkinsci.plugins.workflow.steps.FlowInterruptedException . The problem: AbortException had a "message" which contained the job name/number, along with its status. We used this in our error handling to include context to the error. FlowInterruptedException contains no message, so our error handling fails. Unless I'm missing something, it contains almost no information on what actually failed. Should this bug be re-opened, or a new bug opened to pass FlowInterruptedException some contextual information? EDIT: Here's a code snippet to help explain: try { def results = build job: 'fooJob' def job_number = results.getNumber() } catch (e) { // AbortMessage included a message along the lines of... // "fooJob #13 completed with status FAILURE (propagate: false to ignore)" // We used this message to add context to the error def msg = e.getMessage() // Sadly, this is null for FlowInterruptedException }
            jglick Jesse Glick added a comment -

            Should this bug be re-opened

            As a general rule: no, not unless the originally described bug was not in fact fixed. If a change causes some undesirable behavior, file a separate bug with a Link to the original.

            In this case there is no bug, your script was simply relying on undocumented behavior. The FlowInterruptedException does include all the same information, just in a DownstreamFailureCause rather than the Throwable.message.

            Anyway using a catch block and the exception here was the wrong idiom even before this change. Set propagate: false and inspect the resulting build object’s status and other fields.

            jglick Jesse Glick added a comment - Should this bug be re-opened As a general rule: no, not unless the originally described bug was not in fact fixed. If a change causes some undesirable behavior, file a separate bug with a Link to the original. In this case there is no bug, your script was simply relying on undocumented behavior. The FlowInterruptedException does include all the same information, just in a DownstreamFailureCause rather than the Throwable.message . Anyway using a catch block and the exception here was the wrong idiom even before this change. Set propagate: false and inspect the resulting build object’s status and other fields.

            People

              jglick Jesse Glick
              jlp01 Jesús Lunar Pérez
              Votes:
              5 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: