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

All stages show up as UNSTABLE when only one stage should

    XMLWordPrintable

Details

    • Blue Ocean 1.2-beta2, Blue Ocean 1.2-beta3, Blue Ocean 1.2-beta4, Blue Ocean 1.2, Blue Ocean 1.3, Blue Ocean 1.4 - beta 1
    • Blue Ocean 1.17.0, Pipeline: API 2.34, Pipeline: Basic Steps 2.18, Pipeline: Graph Analysis 1.10, Pipeline: Groovy 2.70, Pipeline: Declarative 1.3.9, JUnit: 1.28, Warnings Next Generation 5.2.0

    Description

      Problem
      When there is a build which has a stage that marks the build as unstable, all the stages, parallels and steps are marked incorrectly as unstable than just the unstable stage, parallel and step that caused the Pipeline to be unstable.

      To reproduce

      1. Build the multibranch pipeline "kzantow/failure-project" from github
      2. Look at the "michaelneale" branch
      3. Note that all stages are unstable (check the api json, all stages are UNSTABLE but should not be, only the final stage should be).

      Attachments

        Issue Links

          is blocked by

          New Feature - A new feature of the product, which has yet to be developed. JENKINS-26522 Annotated block/stage status

          • Major - Major loss of function.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-43995 Individual Pipeline steps and stages/blocks should have Result statuses

          • Critical - Crashes, loss of data, severe memory leak.
          • Resolved
          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-48673 Nodes status are not displayed correctly after aborting an input step

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-45871 Failed test sets all steps to unstable

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-48771 blue ocean not recognizing status change from test evaluation

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-49778 If one stage in the pipeline fails, all the states are marked/color with the same status color

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-56683 Declarative Pipeline: set the build result when tests fail without a script block

          • Major - Major loss of function.
          • Closed
          is related to

          New Feature - A new feature of the product, which has yet to be developed. JENKINS-27092 create a step to abort the build with a NOT_BUILT status

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Reopened

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-53889 Support post conditions that accept a range of stage statuses

          • Major - Major loss of function.
          • Open

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-58783 Update pipeline stage-view-plugin to use the new WarningAction API

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open
          relates to

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-57801 Execution of post stage block is based on pipeline status, not stage result which docs says it should

          • Blocker - Blocks development and/or testing work, production could not run.
          • Open

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-26523 Allow yellow "unstable" state from a step

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-60426 All stages show up as UNSTABLE when one stage is unstable

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-58554 Workflow parse exception with new approach for unstable stages

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-45579 Step to set stage or parallel status

          • Critical - Crashes, loss of data, severe memory leak.
          • Resolved

          Improvement - An improvement or enhancement to an existing feature or task. JENKINS-43292 The failed parallel build step should be focused and aborted when failFast

          • Major - Major loss of function.
          • Resolved
          links to

          Web Link CloudBees Internal UX-663

          Web Link CloudBees Internal UX-663

          Web Link jenkinsci/blueocean-plugin#1954

          Web Link jenkinsci/junit-plugin#118

          Web Link jenkinsci/pipeline-graph-analysis-plugin#25

          Web Link jenkinsci/warnings-ng-plugin#58

          Web Link jenkinsci/workflow-api-plugin#91

          Web Link jenkinsci/workflow-basic-steps-plugin#83

          Activity

            Ascending order - Click to sort in descending order
            View 90 older comments
            brianjmurrell Brian J Murrell added a comment -

            I have read Devin's blog post.  It does not answer my question AFAIU.  But you might think it could because you misunderstood my question.

            My question was not about whole stages running or not running.  Both stages A and B are running.  B was SUCCESSFUL and A was UNSTABLE.  What I am seeing however is that B's post->unstable is being run even though B was successful.

            I am trying to determine if that mis-behaviour is a component of this bug or if this is something different/new.

            brianjmurrell Brian J Murrell added a comment - I have read Devin's blog post.  It does not answer my question AFAIU.  But you might think it could because you misunderstood my question. My question was not about whole stages running or not running.  Both stages A  and B  are running.  B  was SUCCESSFUL  and A  was UNSTABLE .  What I am seeing however is that B 's post -> unstable is being run even though B was successful. I am trying to determine if that mis-behaviour is a component of this bug or if this is something different/new.
            dnusbaum Devin Nusbaum added a comment -

            brianjmurrell Declarative post conditions look at the overall build result, so if a step like unstable or junit marks the build as unstable in stage A and the Pipeline continues executing, unstable post conditions in later stages such as B will execute (unless the build result becomes worse than unstable, e.g. failure). As far as I know Declarative has always worked this way. Before the fix for this issue, both stage A and stage B would have been shown as being unstable in Blue Ocean, but after the fix for this issue, only stage A is shown as unstable (the overall build result was shown as unstable both before and after the fix).

            dnusbaum Devin Nusbaum added a comment - brianjmurrell Declarative post conditions look at the overall build result, so if a step like unstable or junit marks the build as unstable in stage A and the Pipeline continues executing, unstable post conditions in later stages such as B will execute (unless the build result becomes worse than unstable, e.g. failure). As far as I know Declarative has always worked this way. Before the fix for this issue, both stage A and stage B would have been shown as being unstable in Blue Ocean, but after the fix for this issue, only stage A is shown as unstable (the overall build result was shown as unstable both before and after the fix).
            brianjmurrell Brian J Murrell added a comment -

            dnusbaum Whoa!  Are you serious (and sure of what you are saying)?  It seems very un-intuitive, at best, that the status of any individual given stage should be able to alter the status of any other stage.  I would absolutely agree that the outer pipeline {} block's post should be executed per the overall build result, but most certainly not any individual stage.

            I suppose there must be some, can't imagine a use-case where that is useful.  On the contrary, if one has a parallel block of test stages, why would I want the unstable post block of test stage A to run when test stage A passed, but test stage B failed?

            Ultimately, I suppose this should move to a new ticket.  I will open one.  But I probably need to mock up a minimal reproducer before I do.

            brianjmurrell Brian J Murrell added a comment - dnusbaum Whoa!  Are you serious (and sure of what you are saying)?  It seems very un-intuitive,  at best , that the status of any individual given stage should be able to alter the status of any other stage.  I would absolutely agree that the outer pipeline { } block's post should be executed per the overall build result, but most certainly not any individual stage. I suppose there must be some, can't imagine a use-case where that is useful.  On the contrary, if one has a parallel block of test stages, why would I want the unstable post block of test stage A to run when test stage A passed, but test stage B failed? Ultimately, I suppose this should move to a new ticket.  I will open one.  But I probably need to mock up a minimal reproducer before I do.
            brianjmurrell Brian J Murrell added a comment - - edited

            dnusbaum Can you please respond to the previous comment?  Is it really the expected behaviour that all stages in a parallel block execute their post > failure blocks when even just 1 other stage in the parallel group fails?  The result being that stages that actually were successful don't actually process their own post > successful block but instead process their own post -> failure block?

            Quite frankly, this behaviour is hideous.  In my case, a stage is not actually even failing.  In a block of 3 parallel stages if just one of them invokes a catchError(stageResult: 'UNSTABLE', buildResult: 'SUCCESS'), the remaining stages take their post > failure exit path, even though they are SUCCESSFUL, and even though the stage that invoked the catchError() takes it's own post > successful path!

            I cannot imagine how this is not a bug.  This makes catchError(stageResult: 'UNSTABLE', buildResult: 'SUCCESS') quite useless in fact if it can bomb the exit of other stages.

            brianjmurrell Brian J Murrell added a comment - - edited dnusbaum  Can you please respond to the previous comment?  Is it really the expected behaviour that all stages in a parallel block execute their post > failure blocks when even just 1 other stage in the parallel group fails?  The result being that stages that actually were successful don't actually process their own post > successful block but instead process their own post -> failure block? Quite frankly, this behaviour is hideous.  In my case, a stage is not actually even failing.  In a block of 3 parallel stages if just one of them invokes a catchError(stageResult: 'UNSTABLE', buildResult: 'SUCCESS') , the remaining stages take their post > failure exit path, even though they are SUCCESSFUL, and even though the stage that invoked the catchError() takes it's own post > successful path! I cannot imagine how this is not a bug.  This makes catchError(stageResult: 'UNSTABLE', buildResult: 'SUCCESS') quite useless in fact if it can bomb the exit of other stages.
            kon Kalle Niemitalo added a comment - - edited

            JENKINS-57801 has been filed about declarative Pipeline stage post conditions being affected by the result of the whole pipeline.

            kon Kalle Niemitalo added a comment - - edited JENKINS-57801 has been filed about declarative Pipeline stage post conditions being affected by the result of the whole pipeline.

            People

              dnusbaum Devin Nusbaum
              michaelneale Michael Neale
              Votes:
              233 Vote for this issue
              Watchers:
              238 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: