How to debug Azure DevOps report missing

[keegan-conlee-IM]

I have an Azure DevOps pipeline using the Allure Report extension, and it's recently (I think around the v2.2.3 update but I'm not sure) just started giving me the "There is no available report to show!..." message when viewing the report. The "Publish Allure Report" task succeeds and produces no logs whatsoever.

How should I go about debugging this?

[Junaid-PK]

That message normally means the run has no Allure report attachment; it is not just a stale viewer tab.

With PublishAllureReport@2, the default engine is now Allure 3. The most likely update-sensitive case is that the repository has an allurerc.* file whose Awesome plugin is not configured for single-file output. The task can generate the report but skip publishing it, leaving the tab with “There is no available report to show”.

I would debug it in this order:

1. Make the results path explicit. Relative paths are resolved from $(System.DefaultWorkingDirectory), not necessarily the directory where the test command ran.

variables:
  system.debug: true

steps:
  - bash: |
      pwd
      find "$(System.DefaultWorkingDirectory)" -maxdepth 4 -type f \
        \( -name '*-result.json' -o -name '*-container.json' \) -print
    displayName: Locate Allure result files
    condition: always()

  - task: PublishAllureReport@2
    condition: always()
    inputs:
      testResultsDir: '$(System.DefaultWorkingDirectory)/path/to/allure-results'
      reportName: 'Allure Report'

2. Expand the Publish Allure Report step log and look for a warning about the report not being generated in single-file mode. If an allurerc.js / allurerc.mjs exists, enable it:

export default {
  plugins: {
    awesome: {
      options: {
        singleFile: true,
      },
    },
  },
};

If you pass reportDir instead, that directory also has to contain an Allure 3 report generated in single-file mode.

3. As a control, pin the bundled Allure 2 engine:

- task: PublishAllureReport@2
  condition: always()
  inputs:
    testResultsDir: '$(System.DefaultWorkingDirectory)/path/to/allure-results'
    allureVersion: '2.36.0'

If the pinned run publishes while the default does not, the result files are present and the problem is specifically the Allure 3/configuration path introduced by the extension update. If neither publishes, the explicit find output usually reveals a path or skipped-test-step problem.

The current official Azure integration guide documents the same two key constraints—the working-directory-relative results path and mandatory single-file output—and has a troubleshooting section for this exact empty-tab state: https://allurereport.org/docs/integrations-azure/

[keegan-conlee-IM]

All of this I already have set up. The task inputs point to a specific report folder which is generated in single-file mode (yes, I've checked.) The report gets generated correctly by the preceding npx allure generate step, but just doesn't get uploaded. The history appears to be what's causing it for some reason, as when I disable history (in the config file) the report gets uploaded correctly. It could be to do with some of the test results being generated by Allure 2. Neither of these cases generated any logs, in either the npx allure generate or PublishAllureReport steps, just a successful task. If it provides any extra context, this is running on a Windows server, I've had issues because of that before.

This might be a breaking change at this point, but I really think that the PublishAllureReport task not finding any valid reports to upload should result in a "Failed" or "Succeeded With Issues" status. At minimum, it really should generate some log output specifying that it couldn't find any valid reports to upload, and possibly, what it did find and why it wasn't valid (i.e. not generated in single-file mode, or a report directory was specified but no report/no summary.json was found). I at least have the luxury of the pipelines running on a machine I can remote into and see the resulting filesystem, but if this pipeline was running in a container which got disposed of after the pipeline run, I wouldn't even have that.

I've now switched over to the Allure Storage Server, as it handles history better and report load times are much faster (due to the entire report not being bundled in one giant HTML file.) So far, I haven't had any issues with it.