Fix Jenkins JUnit Test Results Not Found After Build (2026)

Jenkins is failing to archive JUnit test results because the build process is not generating the expected XML files in the location Jenkins is configured to look.

Here’s what’s likely happening and how to fix it:

1. Incorrect **/target/surefire-reports/*.xml Pattern

• Diagnosis: The most common culprit is a simple typo or an overly broad glob pattern in the "Post-build Actions" -> "Publish JUnit test result report" configuration. Jenkins expects XML files matching a specific pattern.
• Check: Navigate to your Jenkins job configuration. Under "Post-build Actions," find "Publish JUnit test result report." Examine the "Test report XMLs" field.
• Fix: Ensure the pattern is exactly **/target/surefire-reports/*.xml (or the equivalent for your build tool, e.g., **/build/test-results/**/*.xml for Gradle). This tells Jenkins to look in any subdirectory (**/) for a target/surefire-reports/ folder (common in Maven) and find all .xml files within it.
• Why it works: This pattern precisely targets the default output directory for Maven’s Surefire plugin, which generates the JUnit XML reports. If the pattern is wrong, Jenkins simply won’t see the files.

2. Build Tool Not Generating XML Reports

• Diagnosis: Your build tool (Maven, Gradle, Ant) might not be configured to output test results in the JUnit XML format. By default, some configurations might only produce console output or HTML reports.
• Check:
  • Maven: Look at your pom.xml. Ensure the maven-surefire-plugin is configured and that its configuration doesn’t explicitly disable XML report generation. The default behavior should produce XML.
  • Gradle: Check your build.gradle or build.gradle.kts. The test task should have reports.junit.xml.enabled = true (this is usually the default).
• Fix:
  • Maven: If you’ve customized maven-surefire-plugin, add or ensure the following within its <configuration>:

    <configuration>
        <reportsDirectory>${project.build.directory}/surefire-reports</reportsDirectory>
        <outputName>TEST-${className}</outputName>
        <encoding>UTF-8</encoding>
    </configuration>
    

  • Gradle: In your build.gradle (Groovy):

    test {
        reports {
            junitXml.enabled = true
        }
    }
    

    Or in build.gradle.kts (Kotlin):

    tasks.test {
        reports {
            junitXml.isEnabled = true
        }
    }
    

• Why it works: Explicitly enabling or ensuring the default JUnit XML report generation in your build tool guarantees the necessary files are created in the standard location for Jenkins to find.

3. Test Execution Failure Before Report Generation

• Diagnosis: The build might be failing during test execution, or a critical step before test execution might be failing, preventing the test runner from completing and thus not generating the XML reports.
• Check: Look at the "Console Output" of your Jenkins build. Scroll up from the end. Are there any errors before the point where test results would normally be published? Look for build tool errors, compilation failures, or exceptions during test setup.
• Fix: Address the root cause of the build failure. This could be anything from a compilation error in your code, a missing dependency, an issue with a test setup method (like @BeforeAll or @BeforeClass), or an environment problem. Once the build completes successfully up to and including test execution, reports will be generated.
• Why it works: The JUnit XML reports are a result of successful test execution. If the execution itself is halted by an error, the reports are never written.

4. Incorrect Build Workspace or Relative Paths

• Diagnosis: Jenkins might be looking for the reports in the wrong directory relative to the build’s workspace. This can happen if your build process checks out code into a subdirectory or if your job is configured to run from a specific directory.
• Check: In the Jenkins job configuration, under "General," check the "Custom workspace" setting. Also, examine the "Build Steps" to see if any commands change the directory (cd).
• Fix:
  • If you use a "Custom workspace," ensure the path specified in the JUnit configuration (**/target/surefire-reports/*.xml) is correct relative to that custom workspace.
  • If your build steps cd into a directory, ensure the JUnit report path is specified relative to the final directory where the reports are generated. Often, it’s best to avoid cd in build steps and let the build tool manage paths. If necessary, adjust the JUnit report pattern to be relative to the workspace root, e.g., my-module/target/surefire-reports/*.xml.
• Why it works: Jenkins resolves the report path relative to the build’s workspace root. Mismatched expectations about the current directory lead to Jenkins looking in the wrong place.

5. Build Tool Output Directory Mismatch

• Diagnosis: While less common with standard Maven/Gradle setups, your build tool might be configured to output test reports to a directory other than the default target/surefire-reports/ or build/test-results/.
• Check: Manually run your build command (e.g., mvn clean test or ./gradlew clean test) on the build agent machine. Then, browse the file system to find where the .xml test reports are actually being created.
• Fix: Update the "Test report XMLs" pattern in Jenkins to match the actual output directory. For example, if your build tool outputs to build/reports/tests/test/xml/, you would change the Jenkins pattern to **/build/reports/tests/test/xml/*.xml.
• Why it works: Jenkins needs the exact path where the files are located. If the build tool deviates from convention, Jenkins must be told the new location.

6. Jenkins Agent/Workspace Cleanup Issues

• Diagnosis: In rare cases, if previous builds on the same agent left behind artifacts or corrupted report files, it might interfere, though usually Jenkins is good at cleaning up. More likely, if the workspace wasn’t cleaned properly, Jenkins might be trying to parse old, possibly incomplete, XML files from a prior failed run.
• Check: Manually inspect the workspace on the Jenkins agent for the job. Look for the target/surefire-reports directory. Are the files present? Do they look like valid XML?
• Fix:
  • In the Jenkins job configuration, under "Build Environment," check "Delete workspace before build starts." Enable this option.
  • Alternatively, add a build step before your actual build command that cleans the workspace: rm -rf build/ target/ (adjust for your build tool).
• Why it works: Starting with a clean slate ensures that Jenkins is only attempting to parse reports generated by the current build, free from interference from previous runs.

If you’ve checked all these and still have issues, the next problem you’ll likely encounter is Jenkins complaining about parsing errors in the XML files themselves, indicating a malformed report.