Azure DevOps report having History with Unknown date

[johndiverseqa]

I am generating an allure report from several junit (.xml) results file with the command:

allure awesome /allure-results -o /report --single-file --history-path /allure-results/history.jsonl

the report successfully generated (274ms)

total 2992
-rwxrwxrwx+ 1 65534 65534 3808878 Oct  7 14:34 index.html
-rwxrwxrwx+ 1 65534 65534     371 Oct  7 14:34 summary.json
-rwxrwxrwx+ 1 65534 65534    2235 Oct  7 14:34 test-results.json

Then I publish it using

- task: qameta.allure-azure-pipelines.PublishAllureReport.PublishAllureReport@2
        displayName: Publish an already generated report
        inputs:
          reportDir: '/report'

I have:

Found 1 Allure Report summary file(s).
Uploaded 1 Allure Report summary attachment(s).

When I check the report in Azure Devops, the tests look ok but the history looks like this:

[muhammadmobi]

The date is missing because of the JUnit XML input, not because of Azure DevOps. The history itself works ("History 2"), but each entry has no timestamp.

Why: the History tab shows the entry's stop time, or start + duration, and falls back to "Unknown date" when neither is set (TrHistoryItem.tsx#L16-L28). The JUnit XML reader only takes the time attribute as duration. It sets no start/stop and ignores the <testsuite timestamp> attribute (junitxml/index.ts#L146-L184). History entries copy start/stop from the test result (history.ts#L20-L54), so they never get a date.

Fix: produce native Allure results instead of JUnit XML, using your framework's Allure adapter. They record start/stop for each test. For example, with pytest:

pip install allure-pytest
pytest --alluredir=allure-results
allure awesome allure-results -o report --single-file --history-path allure-results/history.jsonl

Other frameworks are listed in the Allure docs. Entries already in history.jsonl keep "Unknown date", because they were stored without a time. New runs will show it.

If you have to stay on JUnit XML, there's no setting for this today. It's worth opening an issue in allure3 asking the JUnit reader to use the <testsuite timestamp> attribute.