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

When build finishes with failure ("Finished: FAILURE"), report which plugins and/or core components have contributed to the failure


    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Cannot Reproduce
    • Component/s: core
    • Labels:
    • Environment:
      Hudson ver. 1.345, standalone (run with java -jar hudson.war) on Linux i386
    • Similar Issues:


      Currently I have two builds which go fine until they end with the message "Finished: FAILURE" for no apparent reason.

      There are no fatal exceptions nor any errors ("[ERROR]") logged in their output, yet they register red and at the end of build logs I always see:

      [INFO] ------------------------------------------------------------------------
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 21 minutes 47 seconds
      [INFO] Finished at: Tue Feb 09 18:39:19 CET 2010
      [INFO] Final Memory: 74M/392M
      [INFO] ------------------------------------------------------------------------
      channel stopped
      [ANALYSIS-COLLECTOR] Found 36 annotations (0 new, 9 high, 27 normal, 0 low)
      [ANALYSIS-COLLECTOR] Not changing build status, since no threshold has been exceeded
      Publishing Cobertura coverage report...
      No coverage results were found using the pattern '**/target/site/cobertura/coverage.xml' relative to '/opt/hudson/.hudson/jobs/wdx/workspace/wdx'. Did you enter a pattern relative to the correct directory? Did you generate the XML report(s) for Cobertura?
      Sending e-mails to: Aleksander.Adamowski@firstdata.pl
      Finished: FAILURE

      I suspect that the problem lies with the analysis collector or Cobertura plugin. However, this is not the scope of this bug report.

      The purpose of this report is that, in my opinion, the final "Finished" message should output a list of all the plugins and components whose return statuses have triggered changins the overall build status to failure.

      This way the user can immediately identify the cause of the issue instead of sifting through the build log looking for exceptions and error messages which might not be there, or if they are there, they may bear no significance.




            • Assignee:
              olo olo
            • Votes:
              1 Vote for this issue
              2 Start watching this issue


              • Created: