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

Recognize failures indicated by JUnit test result file

      Currently, the build failure analyzer plugin requires the user to explicitly define a match expression for each failure.
      However, many jobs already produce a JUnit result file, where the different testcases are listed, and failed ones are indicated as such.
      It would be great if the build failure analyzer plugin could also use this JUnit file, and automatically report a failure based on the name of the failed testcase (as mentioned in the JUnit result file).

      This avoids users having to create redundant match expressions as the testcases itself already know when something failed.

      A particular case where this is useful is when using the Build Monitor plugin, which has support for Build Failure Analyzer to display the cause of failed builds.

          [JENKINS-25115] Recognize failures indicated by JUnit test result file

          Jan Feindt added a comment - - edited

          This is my use case: some integration tests test business logic where registry keys are used.
          Sometimes there are problems accessing the registry:
          Caused by: java.util.prefs.BackingStoreException: Could not open windowsregistry node Software\JavaSoft\Prefs at root 0x80000001.

          This environment problem should be detected and displayed with an description different from other failing tests.

          The regexp in the given example: .*Could not open windowsregistry node.*

          Jan Feindt added a comment - - edited This is my use case: some integration tests test business logic where registry keys are used. Sometimes there are problems accessing the registry: Caused by: java.util.prefs.BackingStoreException: Could not open windowsregistry node Software\JavaSoft\Prefs at root 0x80000001. This environment problem should be detected and displayed with an description different from other failing tests. The regexp in the given example: .*Could not open windowsregistry node.*

          Thanks, I understand now.
          However, in contrast with the currently proposed implementation, this does require some explicitly added entries in the known failure causes database. So in this case, the comments given by Tomas in the second comment (#comment-214614) do apply. I think such feature could co-exist with the current more simple implementation.

          Thomas De Schampheleire added a comment - Thanks, I understand now. However, in contrast with the currently proposed implementation, this does require some explicitly added entries in the known failure causes database. So in this case, the comments given by Tomas in the second comment (#comment-214614) do apply. I think such feature could co-exist with the current more simple implementation.

          Jan Feindt added a comment -

          Jan Feindt added a comment - opened https://issues.jenkins-ci.org/browse/JENKINS-25437

          Thomas De Schampheleire added a comment - Pull request for the proposed code sent: https://github.com/jenkinsci/build-failure-analyzer-plugin/pull/25

          Seems that this breaks some tests: https://jenkins.ci.cloudbees.com/job/plugins/job/build-failure-analyzer-plugin/75/

          I will look at this. Is it possible to amend to an existing pull request, or should I launch a new one?

          Thomas De Schampheleire added a comment - Seems that this breaks some tests: https://jenkins.ci.cloudbees.com/job/plugins/job/build-failure-analyzer-plugin/75/ I will look at this. Is it possible to amend to an existing pull request, or should I launch a new one?

          Yes it is possible, you simply update your repository that you did the pull request from and the request is updated.

          Tomas Westling added a comment - Yes it is possible, you simply update your repository that you did the pull request from and the request is updated.

          Pull request updated and validated fine this time...

          Thomas De Schampheleire added a comment - Pull request updated and validated fine this time...

          This issue can now be closed after release of 1.11.0

          I do think that the description on https://wiki.jenkins-ci.org/display/JENKINS/Build+Failure+Analyzer
          should be updated to mention the new feature (currently it's only briefly mentioned in the list of releases.

          Thomas De Schampheleire added a comment - This issue can now be closed after release of 1.11.0 I do think that the description on https://wiki.jenkins-ci.org/display/JENKINS/Build+Failure+Analyzer should be updated to mention the new feature (currently it's only briefly mentioned in the list of releases.

          J John added a comment -

          Does this release also parse mstest result files?

          J John added a comment - Does this release also parse mstest result files?

          This change does not handling the parsing of any result files. The parsing happens by a post-build publisher, which can be a JUnit publisher, xUnit publisher, or anything else. These publishers create TestResult objects in Jenkins, which are then read by this plugin.

          Are you already using https://wiki.jenkins-ci.org/display/JENKINS/MSTest+Plugin ?

          Thomas De Schampheleire added a comment - This change does not handling the parsing of any result files. The parsing happens by a post-build publisher, which can be a JUnit publisher, xUnit publisher, or anything else. These publishers create TestResult objects in Jenkins, which are then read by this plugin. Are you already using https://wiki.jenkins-ci.org/display/JENKINS/MSTest+Plugin ?

            t_westling Tomas Westling
            patrickdepinguin Thomas De Schampheleire
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: