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

Error steps may change to show up as errors in pipeline view

    XMLWordPrintable

    Details

    • Similar Issues:
    • Sprint:
      Blue Ocean - Candidates

      Description

      Notes
      This issue needs further investigation

      Original request
      In one of our more complex scripted pipelines with special exception/error handling, the error step visualization keeps changing after a while, so that it does not show the error step as failing anymore (and so also no auto-scroll to error works)!?

      I tried to reproduce it to no avail; this is the basic pipeline code (the last and active section in the code being the closest to the original one):

      node {
          // OK:
          /*
          stage('failing-stage') {
              echo 'hello'
              error 'fail on purpose...'
          }
          */
          
          // OK: shows msg in red and expands it
          /*
          stage('failing-stage') {
              echo 'hello'
              try {
                  error 'fail on purpose...'
              } catch (e) {
                  echo "Caught exception: ${e}"
              }
          }
          */
      
          // OK: shows msg in red and expands it
          /*
          stage('failing-stage') {
              echo 'hello'
              try {
                  error 'fail on purpose...'
              } catch (e) {
                  echo "Caught exception: ${e}"
                  throw e
              }
          }
          */
      
          // OK: shows msg in red and expands it
          stage('failing-stage') {
              echo 'hello'
              try {
                  error 'fail on purpose...'
              } catch (e) {
                  ansiColor('xterm') {
                    echo "\033[1;31mCaught exception: ${e}\033[0m bla bla"
                  }
                  throw e
              } finally {
                  echo "finally"
              }
          }
      }
      

      Initially it works fine and looks like this:

      But at one point it stops showing the error step as error! And the AJAX request that fetches the steps (e.g. https://<JENKINS URL>/blue/rest/organizations/jenkins/pipelines/My-Pipeline/runs/414/nodes/60/steps/) shows matching symptoms:

        Attachments

          Activity

          reinholdfuereder Reinhold Füreder created issue -
          Hide
          jamesdumay James Dumay added a comment -

          Hmm this does seem odd Reinhold Füreder. I was unable to reproduce this with the provided Jenkinsfile (thanks btw!).

          If you are able to capture this problem again, could you grab a HAR file of the session, reopen this ticket and attach it?

          Show
          jamesdumay James Dumay added a comment - Hmm this does seem odd Reinhold Füreder . I was unable to reproduce this with the provided Jenkinsfile (thanks btw!). If you are able to capture this problem again, could you grab a HAR file of the session , reopen this ticket and attach it?
          jamesdumay James Dumay made changes -
          Field Original Value New Value
          Resolution Cannot Reproduce [ 5 ]
          Status Open [ 1 ] Resolved [ 5 ]
          reinholdfuereder Reinhold Füreder made changes -
          Attachment image-2017-10-03-16-39-04-396.png [ 39926 ]
          reinholdfuereder Reinhold Füreder made changes -
          Attachment screenshot-1.png [ 39927 ]
          Hide
          reinholdfuereder Reinhold Füreder added a comment - - edited

          James Dumay Yes, it is definitely odd. And as I wrote, I also failed to re-produce it with the little example. But not sure why: as the initial visualization (i.e. the first time after the notification of the problem) is correct, is it dependent on time or subsequent builds!?

          I have now another example with the bug (of an older – namely from yesterday – build #77):

          When I however break the build now (via replay with bad params => #79) it looks (at least now) fine:

          And here are HAR files (zipped) and Chrome Web Develope Console Tab screenshots for the respective pipeline builds:

          1. The old build #77 with the bug:
          2. The new replayed build #79 one without the bug:

          Interestingly the console error only shows up in/for/during the good visualization (of build #79)! I therefore guess/hope it is another unrelated problem?

          But again the culprit seems to be in the AJAX request that fetches the steps (e.g. https://jenkins2.xortex.com/blue/rest/organizations/jenkins/pipelines/LinkChecker/pipelines/www.....com/runs/77/nodes/20/steps/): where does the underlying information come from? should there be a file somewhere on jenkins server with that information? can there be a weird http proxy server caching problem?

          ...:/var/lib/jenkins/jobs/LinkChecker/jobs/www.....com/builds/77$ cat workflow/63.xml
          <?xml version='1.0' encoding='UTF-8'?>
          <org.jenkinsci.plugins.workflow.support.storage.SimpleXStreamFlowNodeStorage_-Tag plugin="workflow-support@2.15">
            <node class="org.jenkinsci.plugins.workflow.cps.nodes.StepEndNode" plugin="workflow-cps@2.40">
              <parentIds>
                <string>62</string>
              </parentIds>
              <id>63</id>
              <startId>4</startId>
            </node>
            <actions>
              <org.jenkinsci.plugins.workflow.actions.ErrorAction plugin="workflow-api@2.22">
                <error class="hudson.AbortException">
                  <detailMessage>LinkChecker failed: Please check the previous step(s)</detailMessage>
                  <stackTrace>
                    <trace>org.jenkinsci.plugins.workflow.steps.ErrorStep$Execution.run(ErrorStep.java:63)</trace>
                    <trace>org.jenkinsci.plugins.workflow.steps.ErrorStep$Execution.run(ErrorStep.java:50)</trace>
                    <trace>org.jenkinsci.plugins.workflow.steps.SynchronousStepExecution.start(SynchronousStepExecution.java:38)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:224)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:150)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108)</trace>
                    <trace>org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)</trace>
                    <trace>org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)</trace>
                    <trace>org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)</trace>
                    <trace>com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:19)</trace>
                    <trace>acme.fail(/var/lib/jenkins/jobs/LinkChecker/jobs/www.....com/builds/77/libs/acme-shared-library/vars/acme.groovy:86)</trace>
                    <trace>com.acme.linkchecker.LinkCheckerStep.execute(file:/var/lib/jenkins/jobs/LinkChecker/jobs/www.....com/builds/77/libs/acme-shared-library/src/com/acme/linkchecker/LinkCheckerStep.groovy:55)</trace>
                    <trace>org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:129)</trace>
                    <trace>___cps.transform___(Native Method)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)</trace>
                    <trace>sun.reflect.GeneratedMethodAccessor216.invoke(Unknown Source)</trace>
                    <trace>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)</trace>
                    <trace>java.lang.reflect.Method.invoke(Method.java:498)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:103)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)</trace>
                    <trace>sun.reflect.GeneratedMethodAccessor216.invoke(Unknown Source)</trace>
                    <trace>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)</trace>
                    <trace>java.lang.reflect.Method.invoke(Method.java:498)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:60)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)</trace>
                    <trace>sun.reflect.GeneratedMethodAccessor216.invoke(Unknown Source)</trace>
                    <trace>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)</trace>
                    <trace>java.lang.reflect.Method.invoke(Method.java:498)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)</trace>
                    <trace>com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)</trace>
                    <trace>com.cloudbees.groovy.cps.Next.step(Next.java:83)</trace>
                    <trace>com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174)</trace>
                    <trace>com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163)</trace>
                    <trace>org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122)</trace>
                    <trace>org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261)</trace>
                    <trace>com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:35)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:32)</trace>
                    <trace>org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:32)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:330)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:82)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:242)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:230)</trace>
                    <trace>org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)</trace>
                    <trace>java.util.concurrent.FutureTask.run(FutureTask.java:266)</trace>
                    <trace>hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)</trace>
                    <trace>jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)</trace>
                    <trace>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)</trace>
                    <trace>java.util.concurrent.FutureTask.run(FutureTask.java:266)</trace>
                    <trace>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)</trace>
                    <trace>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)</trace>
                    <trace>java.lang.Thread.run(Thread.java:748)</trace>
                  </stackTrace>
                  <suppressedExceptions class="java.util.Collections$UnmodifiableRandomAccessList" resolves-to="java.util.Collections$UnmodifiableList">
                    <c class="list"/>
                    <list reference="../c"/>
                  </suppressedExceptions>
                </error>
              </org.jenkinsci.plugins.workflow.actions.ErrorAction>
              <org.jenkinsci.plugins.workflow.actions.TimingAction plugin="workflow-api@2.22">
                <startTime>1506913971139</startTime>
              </org.jenkinsci.plugins.workflow.actions.TimingAction>
              <org.jenkinsci.plugins.workflow.actions.ErrorAction plugin="workflow-api@2.22">
                <error class="hudson.AbortException" reference="../../org.jenkinsci.plugins.workflow.actions.ErrorAction/error"/>
              </org.jenkinsci.plugins.workflow.actions.ErrorAction>
            </actions>
          
          Show
          reinholdfuereder Reinhold Füreder added a comment - - edited James Dumay Yes, it is definitely odd. And as I wrote, I also failed to re-produce it with the little example. But not sure why: as the initial visualization (i.e. the first time after the notification of the problem) is correct, is it dependent on time or subsequent builds!? I have now another example with the bug (of an older – namely from yesterday – build #77): When I however break the build now (via replay with bad params => #79) it looks (at least now) fine: And here are HAR files (zipped) and Chrome Web Develope Console Tab screenshots for the respective pipeline builds: The old build #77 with the bug: linkchecker-77-with-bug.zip The new replayed build #79 one without the bug: linkchecker-79-without-bug.zip Interestingly the console error only shows up in/for/during the good visualization (of build #79)! I therefore guess/hope it is another unrelated problem? But again the culprit seems to be in the AJAX request that fetches the steps (e.g. https://jenkins2.xortex.com/blue/rest/organizations/jenkins/pipelines/LinkChecker/pipelines/www.....com/runs/77/nodes/20/steps/): where does the underlying information come from? should there be a file somewhere on jenkins server with that information? can there be a weird http proxy server caching problem? ...:/var/lib/jenkins/jobs/LinkChecker/jobs/www.....com/builds/77$ cat workflow/63.xml <?xml version= '1.0' encoding= 'UTF-8' ?> <org.jenkinsci.plugins.workflow.support.storage.SimpleXStreamFlowNodeStorage_-Tag plugin= "workflow-support@2.15" > <node class= "org.jenkinsci.plugins.workflow.cps.nodes.StepEndNode" plugin= "workflow-cps@2.40" > <parentIds> <string> 62 </string> </parentIds> <id> 63 </id> <startId> 4 </startId> </node> <actions> <org.jenkinsci.plugins.workflow.actions.ErrorAction plugin= "workflow-api@2.22" > <error class= "hudson.AbortException" > <detailMessage> LinkChecker failed: Please check the previous step(s) </detailMessage> <stackTrace> <trace> org.jenkinsci.plugins.workflow.steps.ErrorStep$Execution.run(ErrorStep.java:63) </trace> <trace> org.jenkinsci.plugins.workflow.steps.ErrorStep$Execution.run(ErrorStep.java:50) </trace> <trace> org.jenkinsci.plugins.workflow.steps.SynchronousStepExecution.start(SynchronousStepExecution.java:38) </trace> <trace> org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:224) </trace> <trace> org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:150) </trace> <trace> org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108) </trace> <trace> org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48) </trace> <trace> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) </trace> <trace> org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) </trace> <trace> com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:19) </trace> <trace> acme.fail(/var/lib/jenkins/jobs/LinkChecker/jobs/www.....com/builds/77/libs/acme-shared-library/vars/acme.groovy:86) </trace> <trace> com.acme.linkchecker.LinkCheckerStep.execute(file:/var/lib/jenkins/jobs/LinkChecker/jobs/www.....com/builds/77/libs/acme-shared-library/src/com/acme/linkchecker/LinkCheckerStep.groovy:55) </trace> <trace> org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(jar:file:/var/lib/jenkins/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:129) </trace> <trace> ___cps.transform___(Native Method) </trace> <trace> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57) </trace> <trace> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109) </trace> <trace> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82) </trace> <trace> sun.reflect.GeneratedMethodAccessor216.invoke(Unknown Source) </trace> <trace> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) </trace> <trace> java.lang.reflect.Method.invoke(Method.java:498) </trace> <trace> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) </trace> <trace> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:103) </trace> <trace> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82) </trace> <trace> sun.reflect.GeneratedMethodAccessor216.invoke(Unknown Source) </trace> <trace> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) </trace> <trace> java.lang.reflect.Method.invoke(Method.java:498) </trace> <trace> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) </trace> <trace> com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:60) </trace> <trace> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109) </trace> <trace> com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82) </trace> <trace> sun.reflect.GeneratedMethodAccessor216.invoke(Unknown Source) </trace> <trace> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) </trace> <trace> java.lang.reflect.Method.invoke(Method.java:498) </trace> <trace> com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) </trace> <trace> com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) </trace> <trace> com.cloudbees.groovy.cps.Next.step(Next.java:83) </trace> <trace> com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174) </trace> <trace> com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163) </trace> <trace> org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122) </trace> <trace> org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261) </trace> <trace> com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163) </trace> <trace> org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19) </trace> <trace> org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:35) </trace> <trace> org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:32) </trace> <trace> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108) </trace> <trace> org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:32) </trace> <trace> org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174) </trace> <trace> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:330) </trace> <trace> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:82) </trace> <trace> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:242) </trace> <trace> org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:230) </trace> <trace> org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64) </trace> <trace> java.util.concurrent.FutureTask.run(FutureTask.java:266) </trace> <trace> hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) </trace> <trace> jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) </trace> <trace> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) </trace> <trace> java.util.concurrent.FutureTask.run(FutureTask.java:266) </trace> <trace> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) </trace> <trace> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) </trace> <trace> java.lang.Thread.run(Thread.java:748) </trace> </stackTrace> <suppressedExceptions class= "java.util.Collections$UnmodifiableRandomAccessList" resolves-to= "java.util.Collections$UnmodifiableList" > <c class= "list" /> <list reference= "../c" /> </suppressedExceptions> </error> </org.jenkinsci.plugins.workflow.actions.ErrorAction> <org.jenkinsci.plugins.workflow.actions.TimingAction plugin= "workflow-api@2.22" > <startTime> 1506913971139 </startTime> </org.jenkinsci.plugins.workflow.actions.TimingAction> <org.jenkinsci.plugins.workflow.actions.ErrorAction plugin= "workflow-api@2.22" > <error class= "hudson.AbortException" reference= "../../org.jenkinsci.plugins.workflow.actions.ErrorAction/error" /> </org.jenkinsci.plugins.workflow.actions.ErrorAction> </actions>
          reinholdfuereder Reinhold Füreder made changes -
          Attachment linkchecker-77-with-bug.PNG [ 39928 ]
          Attachment linkchecker-79-without-bug.PNG [ 39929 ]
          reinholdfuereder Reinhold Füreder made changes -
          Attachment linkchecker-77-with-bug.zip [ 39930 ]
          Attachment linkchecker-79-without-bug.zip [ 39931 ]
          reinholdfuereder Reinhold Füreder made changes -
          Resolution Cannot Reproduce [ 5 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          jamesdumay James Dumay made changes -
          Rank Ranked higher
          jamesdumay James Dumay made changes -
          Epic Link JENKINS-43953 [ 181485 ]
          jamesdumay James Dumay made changes -
          Sprint Blue Ocean 1.4 - beta 2 [ 416 ]
          Description In one of our more complex scripted pipelines with special exception/error handling, the error step visualization keeps changing after a while, so that it does not show the error step as failing anymore (and so also no auto-scroll to error works)!?

          I tried to reproduce it to no avail; this is the basic pipeline code (the last and active section in the code being the closest to the original one):
          {code:java}
          node {
              // OK:
              /*
              stage('failing-stage') {
                  echo 'hello'
                  error 'fail on purpose...'
              }
              */
              
              // OK: shows msg in red and expands it
              /*
              stage('failing-stage') {
                  echo 'hello'
                  try {
                      error 'fail on purpose...'
                  } catch (e) {
                      echo "Caught exception: ${e}"
                  }
              }
              */

              // OK: shows msg in red and expands it
              /*
              stage('failing-stage') {
                  echo 'hello'
                  try {
                      error 'fail on purpose...'
                  } catch (e) {
                      echo "Caught exception: ${e}"
                      throw e
                  }
              }
              */

              // OK: shows msg in red and expands it
              stage('failing-stage') {
                  echo 'hello'
                  try {
                      error 'fail on purpose...'
                  } catch (e) {
                      ansiColor('xterm') {
                        echo "\033[1;31mCaught exception: ${e}\033[0m bla bla"
                      }
                      throw e
                  } finally {
                      echo "finally"
                  }
              }
          }
          {code}

          Initially it works fine and looks like this:
          !image-2017-09-07-14-44-27-695.png|thumbnail!

          But at one point it stops showing the error step as error! And the AJAX request that fetches the steps (e.g. https://&lt;JENKINS URL>/blue/rest/organizations/jenkins/pipelines/My-Pipeline/runs/414/nodes/60/steps/) shows matching symptoms:

           !image-2017-09-07-14-50-42-300.png|thumbnail!
          *Notes*
          This issue needs further investigation

          *Original request*
          In one of our more complex scripted pipelines with special exception/error handling, the error step visualization keeps changing after a while, so that it does not show the error step as failing anymore (and so also no auto-scroll to error works)!?

          I tried to reproduce it to no avail; this is the basic pipeline code (the last and active section in the code being the closest to the original one):
          {code:java}
          node {
              // OK:
              /*
              stage('failing-stage') {
                  echo 'hello'
                  error 'fail on purpose...'
              }
              */
              
              // OK: shows msg in red and expands it
              /*
              stage('failing-stage') {
                  echo 'hello'
                  try {
                      error 'fail on purpose...'
                  } catch (e) {
                      echo "Caught exception: ${e}"
                  }
              }
              */

              // OK: shows msg in red and expands it
              /*
              stage('failing-stage') {
                  echo 'hello'
                  try {
                      error 'fail on purpose...'
                  } catch (e) {
                      echo "Caught exception: ${e}"
                      throw e
                  }
              }
              */

              // OK: shows msg in red and expands it
              stage('failing-stage') {
                  echo 'hello'
                  try {
                      error 'fail on purpose...'
                  } catch (e) {
                      ansiColor('xterm') {
                        echo "\033[1;31mCaught exception: ${e}\033[0m bla bla"
                      }
                      throw e
                  } finally {
                      echo "finally"
                  }
              }
          }
          {code}

          Initially it works fine and looks like this:
          !image-2017-09-07-14-44-27-695.png|thumbnail!

          But at one point it stops showing the error step as error! And the AJAX request that fetches the steps (e.g. https://&lt;JENKINS URL>/blue/rest/organizations/jenkins/pipelines/My-Pipeline/runs/414/nodes/60/steps/) shows matching symptoms:

           !image-2017-09-07-14-50-42-300.png|thumbnail!
          jamesdumay James Dumay made changes -
          Sprint Blue Ocean 1.4 - beta 3 [ 416 ] Blue Ocean 1.4 - beta 4 [ 441 ]
          Hide
          tscherler Thorsten Scherler added a comment -

          Reinhold Füreder to track down the root cause I would need to know what the classic UI is showing. I mean if the classic UI is showing the error but BO not then we know that it is specific to BO but if the classic UI shows the same problems then there is a general issue.

          Show
          tscherler Thorsten Scherler added a comment - Reinhold Füreder to track down the root cause I would need to know what the classic UI is showing. I mean if the classic UI is showing the error but BO not then we know that it is specific to BO but if the classic UI shows the same problems then there is a general issue.
          reinholdfuereder Reinhold Füreder made changes -
          Attachment image-2018-10-30-12-30-10-803.png [ 44913 ]
          reinholdfuereder Reinhold Füreder made changes -
          Attachment image-2018-10-30-12-32-53-068.png [ 44914 ]
          Hide
          reinholdfuereder Reinhold Füreder added a comment -

          Thorsten Scherler First of all thanks a lot in advance for taking care of this mysterious and disturbing problem

          The classic UI shows the error as expected:

          1. Of course the build itself is red (but this is also the case in BO)
          2. The console log contains the error step output at the very end:
            ...
            > Task :migrateDb FAILEDFAILURE: Build failed with an exception.* What went wrong:
            Execution failed for task ':migrateDb'.
            > Process 'command 'php'' finished with non-zero exit value 1* Try:
            Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.* Get more help at https://help.gradle.orgBUILD FAILED in 14s
            2 actionable tasks: 1 executed, 1 up-to-date
            [Pipeline] echo
            [DEBUG] gradlew phpunit exit code: 1
            [Pipeline] pwd
            [Pipeline] error
            [Pipeline] }
            $ docker stop --time=1 2d13f6eb6583a72e93035a276888210f140b200ab6e7533144bf017ad1f13965
            $ docker rm -f 2d13f6eb6583a72e93035a276888210f140b200ab6e7533144bf017ad1f13965
            [Pipeline] // withDockerContainer
            [Pipeline] }
            [Pipeline] // withDockerRegistry
            [Pipeline] }
            [Pipeline] // withEnv
            [Pipeline] }
            [Pipeline] // withEnv
            [Pipeline] sh
            [ACME-Pipeline-WS] Running shell script
            + docker stop d94a0bd920c35a4e98559980b9409c0ecc8d3db2d062ce7b6de07f350d1dcd0b
            d94a0bd920c35a4e98559980b9409c0ecc8d3db2d062ce7b6de07f350d1dcd0b
            + docker rm -f d94a0bd920c35a4e98559980b9409c0ecc8d3db2d062ce7b6de07f350d1dcd0b
            d94a0bd920c35a4e98559980b9409c0ecc8d3db2d062ce7b6de07f350d1dcd0b
            [Pipeline] }
            [Pipeline] // withDockerRegistry
            [Pipeline] }
            [Pipeline] // withEnv
            [Pipeline] }
            [Pipeline] // ws
            [Pipeline] }
            [Pipeline] // node
            [Pipeline] }
            [Pipeline] // stage
            [Pipeline] ansiColor
            [Pipeline] {
            [Pipeline] echo
            Pipeline problem: PHPUnit DB integration test execution failed completely due to: "hudson.AbortException: PHPUnit DB integration test execution failed completely: Please check the previous step(s)" => Please check the "Console/Log Output" => Failure notification will be sent...
            [Pipeline] }
            [Pipeline] // ansiColor
            [Pipeline] emailextrecipients
            [Pipeline] emailextrecipients
            [Pipeline] emailextrecipients
            [Pipeline] emailextrecipients
            [Pipeline] emailextrecipients
            [Pipeline] emailextrecipients
            [Pipeline] echo
            email-ext-recipients:
              	failingTestSuspects: 
              	failingBuildSuspects: 
              	developers: a.name@acme.com
              	culprits: a.name@acme.com
              	requester: 
              	upstreamCommitters: 
            [Pipeline] emailext
            Single culprit: [A Name]
            Sending email to: a.name@acme.com jenkins.ci.cd@acme.com
            [Pipeline] stage
            [Pipeline] { (kpi)
            [Pipeline] echo
            Listing all KPIs...
            [Pipeline] echo[Pipeline] node
            Running on Jenkins in /var/lib/jenkins/workspace/ACME-Pipeline
            [Pipeline] {
            [Pipeline] ws
            Running in /var/lib/jenkins/workspace/ACME-Pipeline-WS-kpi
            [Pipeline] {
            [Pipeline] echo
            Build Pipeline KPIs:
              - Build duration: 2 minutes, 49.844 seconds ... time duration since build start
              - Time duration since build scheduling: 2 minutes, 49.857 seconds
              - Pipeline net execution time duration: 2 minutes, 42.368 seconds ... in "acme.build"
              - Cycle time: 2 minutes, 50.570 seconds ... time duration since (oldest included production code) SVN commit (170953)
            [Pipeline] echo
            Stage completion times ... time between SVN commit and end of stage:
              - "checkout": 1 minutes, 33.175 seconds
              - "docker-unit-tests": 2 minutes, 7.690 seconds
              - "docker-db-integration-tests": 2 minutes, 47.984 seconds
            [Pipeline] pwd
            [Pipeline] plot
            [Pipeline] }
            [Pipeline] // ws
            [Pipeline] }
            [Pipeline] // node
            [Pipeline] }
            [Pipeline] // stage
            [Pipeline] End of Pipeline
            ERROR: PHPUnit DB integration test execution failed completely: Please check the previous step(s)
            Finished: FAILURE
          1. And in "Pipeline Steps" view it shows:

           

          For this build BO actually looks like this:

          That is, it does not highlight the failing stage, and presumably therefore also does not auto-scroll to the error step?

           

          Do you need anything else?

          (I will look for other recent occurrences to check if they are consistent with this one.)

          Show
          reinholdfuereder Reinhold Füreder added a comment - Thorsten Scherler First of all thanks a lot in advance for taking care of this mysterious and disturbing problem The classic UI shows the error as expected: Of course the build itself is red (but this is also the case in BO) The console log contains the error step output at the very end: ... > Task :migrateDb FAILEDFAILURE: Build failed with an exception.* What went wrong: Execution failed for task ':migrateDb'. > Process 'command 'php'' finished with non-zero exit value 1* Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.* Get more help at https://help.gradle.orgBUILD FAILED in 14s 2 actionable tasks: 1 executed, 1 up-to-date [Pipeline] echo [DEBUG] gradlew phpunit exit code: 1 [Pipeline] pwd [Pipeline] error [Pipeline] } $ docker stop --time=1 2d13f6eb6583a72e93035a276888210f140b200ab6e7533144bf017ad1f13965 $ docker rm -f 2d13f6eb6583a72e93035a276888210f140b200ab6e7533144bf017ad1f13965 [Pipeline] // withDockerContainer [Pipeline] } [Pipeline] // withDockerRegistry [Pipeline] } [Pipeline] // withEnv [Pipeline] } [Pipeline] // withEnv [Pipeline] sh [ACME-Pipeline-WS] Running shell script + docker stop d94a0bd920c35a4e98559980b9409c0ecc8d3db2d062ce7b6de07f350d1dcd0b d94a0bd920c35a4e98559980b9409c0ecc8d3db2d062ce7b6de07f350d1dcd0b + docker rm -f d94a0bd920c35a4e98559980b9409c0ecc8d3db2d062ce7b6de07f350d1dcd0b d94a0bd920c35a4e98559980b9409c0ecc8d3db2d062ce7b6de07f350d1dcd0b [Pipeline] } [Pipeline] // withDockerRegistry [Pipeline] } [Pipeline] // withEnv [Pipeline] } [Pipeline] // ws [Pipeline] } [Pipeline] // node [Pipeline] } [Pipeline] // stage [Pipeline] ansiColor [Pipeline] { [Pipeline] echo Pipeline problem: PHPUnit DB integration test execution failed completely due to: "hudson.AbortException: PHPUnit DB integration test execution failed completely: Please check the previous step(s)" => Please check the "Console/Log Output" => Failure notification will be sent... [Pipeline] } [Pipeline] // ansiColor [Pipeline] emailextrecipients [Pipeline] emailextrecipients [Pipeline] emailextrecipients [Pipeline] emailextrecipients [Pipeline] emailextrecipients [Pipeline] emailextrecipients [Pipeline] echo email-ext-recipients: failingTestSuspects: failingBuildSuspects: developers: a.name@acme.com culprits: a.name@acme.com requester: upstreamCommitters: [Pipeline] emailext Single culprit: [A Name] Sending email to: a.name@acme.com jenkins.ci.cd@acme.com [Pipeline] stage [Pipeline] { (kpi) [Pipeline] echo Listing all KPIs... [Pipeline] echo[Pipeline] node Running on Jenkins in /var/lib/jenkins/workspace/ACME-Pipeline [Pipeline] { [Pipeline] ws Running in /var/lib/jenkins/workspace/ACME-Pipeline-WS-kpi [Pipeline] { [Pipeline] echo Build Pipeline KPIs: - Build duration: 2 minutes, 49.844 seconds ... time duration since build start - Time duration since build scheduling: 2 minutes, 49.857 seconds - Pipeline net execution time duration: 2 minutes, 42.368 seconds ... in "acme.build" - Cycle time: 2 minutes, 50.570 seconds ... time duration since (oldest included production code) SVN commit (170953) [Pipeline] echo Stage completion times ... time between SVN commit and end of stage: - "checkout": 1 minutes, 33.175 seconds - "docker-unit-tests": 2 minutes, 7.690 seconds - "docker-db-integration-tests": 2 minutes, 47.984 seconds [Pipeline] pwd [Pipeline] plot [Pipeline] } [Pipeline] // ws [Pipeline] } [Pipeline] // node [Pipeline] } [Pipeline] // stage [Pipeline] End of Pipeline ERROR: PHPUnit DB integration test execution failed completely: Please check the previous step(s) Finished: FAILURE And in "Pipeline Steps" view it shows:   For this build BO actually looks like this: That is, it does not highlight the failing stage, and presumably therefore also does not auto-scroll to the error step?   Do you need anything else? (I will look for other recent occurrences to check if they are consistent with this one.)
          reinholdfuereder Reinhold Füreder made changes -
          Attachment TK-Branch-am-selben-Tag.png [ 45000 ]
          Attachment TK-Branch-am-selben-Tag-ClassicUI.png [ 45001 ]
          reinholdfuereder Reinhold Füreder made changes -
          Hide
          reinholdfuereder Reinhold Füreder added a comment - - edited

          Thorsten Scherler Yesterday I provoked an artifical new/up-to-date reproducer (version information: Jenkins Core 2.147, Jenkins Blue Ocean Plugin 1.9.0) by adding an error step at around the same point in the pipeline stage and while it looked OK immediately (or maybe ~1h) afterwards, this morning it is NOT anymore!

          1. Initially it is still OK:
            1. BO:
            2. Classic "Steps" view:
          2. Today it is broken:
            1. BO for pipeline:
            2. BO when selecting broken stage in pipeline:
          Show
          reinholdfuereder Reinhold Füreder added a comment - - edited Thorsten Scherler Yesterday I provoked an artifical new/up-to-date reproducer (version information: Jenkins Core 2.147, Jenkins Blue Ocean Plugin 1.9.0) by adding an error step at around the same point in the pipeline stage and while it looked OK immediately (or maybe ~1h) afterwards , this morning it is NOT anymore! Initially it is still OK: BO: Classic "Steps" view: Today it is broken: BO for pipeline: BO when selecting broken stage in pipeline:
          reinholdfuereder Reinhold Füreder made changes -
          reinholdfuereder Reinhold Füreder made changes -
          Attachment TK-Branch-am-selben-Tag-ClassicUI.png [ 45001 ]
          reinholdfuereder Reinhold Füreder made changes -
          Attachment image-2018-11-13-10-19-20-710.png [ 45141 ]
          Hide
          reinholdfuereder Reinhold Füreder added a comment -

          I have just seen that the same bug seems to pop up also in (one of my few) declarative pipelines:

          • Besides not showing the failing stage in BO, it actually also manifests in stages with 0ms duration in the Stage View (see the three blue lightnings in the screenshot)
          • Today's build (see the second build from top that is highlighted in yellow in the screenshot; mind it was just 2 hours ago) is still OK, but I assume/guess it will show up wrongly tomorrow
          • The last/bottom one is also OK, because it actually failed due to a non-zero exit code in shell script (and not by calling "error" step):
            [Pipeline] End of Pipeline
            ERROR: script returned exit code 1
            Finished: FAILURE

          => So I guess/claim this bug is somehow related to calling the "error" step explicitly in the pipeline; in my case this happens within a shared pipeline library, but in the example of issue description this was not the case

          Show
          reinholdfuereder Reinhold Füreder added a comment - I have just seen that the same bug seems to pop up also in (one of my few) declarative pipelines : Besides not showing the failing stage in BO, it actually also manifests in stages with 0ms duration in the Stage View (see the three blue lightnings in the screenshot) Today's build (see the second build from top that is highlighted in yellow in the screenshot; mind it was just 2 hours ago) is still OK, but I assume/guess it will show up wrongly tomorrow The last/bottom one is also OK, because it actually failed due to a non-zero exit code in shell script (and not by calling "error" step): [Pipeline] End of Pipeline ERROR: script returned exit code 1 Finished: FAILURE => So I guess/claim this bug is somehow related to calling the "error" step explicitly in the pipeline ; in my case this happens within a shared pipeline library, but in the example of issue description this was not the case

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            reinholdfuereder Reinhold Füreder
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Dates

              Created:
              Updated: