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

Individual Pipeline steps and stages/blocks should have Result statuses

    • Pipeline - July/August, Pipeline - October, Pipeline - April 2018
    • Pipeline: API 2.34

      Problem
      Currently, the only status we have for an individual FlowNode (be it representing an atomic Step or a block) is whether it has an ErrorAction. Blue Ocean would like to be able to visualize other Result types (such as UNSTABLE and ABORTED) distinctly, as well as to be able to have all steps/blocks get marked as UNSTABLE or ABORTED if only one step/block actually is unstable or was aborted.

      Approach
      We want to have a shared understanding of how the status system should work before we attempt a long refactor of the Pipeline status system. The first goal is to build a throwaway simulator that we can use to describe a Pipeline, the status of its steps and what the resulting stage, parallel and pipeline status should be. This is used to develop a set of scenarios that will be used to define the specification for the refactor.

      Before moving onto the real changes there must be consensus among the team that this is the desired behaviour.

          [JENKINS-43995] Individual Pipeline steps and stages/blocks should have Result statuses

          I'd like to add a vote for this. This is needed for many things, such as:

          • sending "fixed" notifications for stages in long running pipelines (right now I see only a way to send such notifications for the whole pipeline, which is not the same thing)
          • skipping stages for long running pipelines that have failed at a certain stage (you tag pipeline build 1, stages 1-5 with their git hash upon successful execution; during pipeline build 2 each stage checks its current git hash against the tag from build 1, if the values are the same, it means that the stage has already been successfully executed, so the stage is skipped)

          Basically having (possibly custom) metadata for all stages for old builds is very useful since we can query it in subsequent builds and do smart things©.

          Costin Caraivan added a comment - I'd like to add a vote for this. This is needed for many things, such as: sending "fixed" notifications for stages in long running pipelines (right now I see only a way to send such notifications for the whole pipeline, which is not the same thing) skipping stages for long running pipelines that have failed at a certain stage (you tag pipeline build 1, stages 1-5 with their git hash upon successful execution; during pipeline build 2 each stage checks its current git hash against the tag from build 1, if the values are the same, it means that the stage has already been successfully executed, so the stage is skipped) Basically having (possibly custom) metadata for all stages for old builds is very useful since we can query it in subsequent builds and do smart things ©.

          This is a big problem in all the project in the company that I work. People are losing their trust in the pipeline as code and want to go back to the old ways since they can't see the result of their individual stages.

          Parisa Mirshams added a comment - This is a big problem in all the project in the company that I work. People are losing their trust in the pipeline as code and want to go back to the old ways since they can't see the result of their individual stages.

          Sam Van Oort added a comment -

          eparimi I've provided a workaround in the other related ticket you commented on.  I think there is not a need to be dramatic about this, because it primarily impacts visualization with special statuses and has no impact on whether pipelines actually complete or not.  But if it's that critical for you, please feel free to submit a PR.

          Sam Van Oort added a comment - eparimi I've provided a workaround in the other related ticket you commented on.  I think there is not a need to be dramatic about this, because it primarily impacts visualization with special statuses and has no impact on whether pipelines actually complete or not.  But if it's that critical for you, please feel free to submit a PR.

          svanoort: Would be great to know the place where you described the workaround so I can have a look. Could you please post a link. Thanks.

          Joerg Schwaerzler added a comment - svanoort : Would be great to know the place where you described the workaround so I can have a look. Could you please post a link. Thanks.

          Yin Ly added a comment -

          I found this workaround: https://stackoverflow.com/a/47794397

          It took a little bit to work out for my case, but it ends up giving me what I need - stage failures look different from the successful ones.  This is an acceptable short term workaround for me in order to get a good quick glance of stages which are failing.   

          Yin Ly added a comment - I found this workaround: https://stackoverflow.com/a/47794397 It took a little bit to work out for my case, but it ends up giving me what I need - stage failures look different from the successful ones.  This is an acceptable short term workaround for me in order to get a good quick glance of stages which are failing.   

          Surya Bharath Bommadevara added a comment - - edited

          yinly: The workaround you mentioned does it mark stages in parallel also as failed and not the entire pipeline. Can you also provide us your workaround if possible. Thanks in advance.

          Surya Bharath Bommadevara added a comment - - edited yinly : The workaround you mentioned does it mark stages in parallel also as failed and not the entire pipeline. Can you also provide us your workaround if possible. Thanks in advance.

          Yin Ly added a comment -

          suryabharath, here is my workaround:  https://gist.github.com/yin042018/f7a65e9e9b93c828377ab939c5fbd6b6

          My use case is running rspec regression tests.

          I have not tried with parallel stages for different reasons.  I am doubtful it would work since I had to wrap a try around each stage.  It looks like parallel should wrap stages.  

           

           

          Yin Ly added a comment - suryabharath , here is my workaround:   https://gist.github.com/yin042018/f7a65e9e9b93c828377ab939c5fbd6b6 My use case is running rspec regression tests. I have not tried with parallel stages for different reasons.  I am doubtful it would work since I had to wrap a try around each stage.  It looks like parallel should wrap stages.      

          Frederic Rousseau added a comment - - edited

          Hello svanoort, I don't really understand for which sprint this improvement is planned for. Last April? This issue blocks issue JENKINS-39203 which is the second most voted for open Bug on this Jira. We are a lot actively waiting for resolution! jql search on votes >= 99 AND Type = Bug AND status != Closed AND status != Resolved

          Frederic Rousseau added a comment - - edited Hello svanoort , I don't really understand for which sprint this improvement is planned for. Last April? This issue blocks issue  JENKINS-39203  which is the second most voted for open Bug on this Jira. We are a lot actively waiting for resolution!  jql search on votes >= 99 AND Type = Bug AND status != Closed AND status != Resolved

          Saad Azam added a comment -

          In my humble opinion this is one of the basic features missing in the pipeline and should be on high priority. All the solutions that have been described previously as workarounds such as using try-catch do not work for a declarative pipeline.

          Saad Azam added a comment - In my humble opinion this is one of the basic features missing in the pipeline and should be on high priority. All the solutions that have been described previously as workarounds such as using try-catch do not work for a declarative pipeline.

          Devin Nusbaum added a comment -

          As of Pipeline: API 2.34, Pipeline steps are able to use the new WarningAction API to identify that some non-fatal event occurred during the execution of a step but execution continued normally. Visualizations are able to access this new action and use them to change how visualizations are displayed. See this comment on JENKINS-39203 for additional details.

          Devin Nusbaum added a comment - As of Pipeline: API 2.34, Pipeline steps are able to use the new WarningAction API to identify that some non-fatal event occurred during the execution of a step but execution continued normally. Visualizations are able to access this new action and use them to change how visualizations are displayed. See this comment on JENKINS-39203 for additional details.

            dnusbaum Devin Nusbaum
            abayer Andrew Bayer
            Votes:
            131 Vote for this issue
            Watchers:
            148 Start watching this issue

              Created:
              Updated:
              Resolved: