Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
(Fix): Parses correct timestamp from test suites (#215)
Fixes issues in #209, and verified on the _actual_ bundle junits we were seeing in https://github.com/trunk-io/trunk/actions/runs/12267338838/job/34227320055?pr=19962 ![Screenshot 2024-12-11 at 1 27 13 AM](https://github.com/user-attachments/assets/000f6bc1-070d-42a7-9be9-c62a027fca9e) - `timestamp` _is not_ an actual part of the well-accepted JUnit spec for [**test cases**](https://github.com/nextest-rs/quick-junit/blob/main/src/report.rs#L309-L312)--only some tools support it, including our C++ test reporters, which I had been using for testing before - `timestamp` _is_ a more common part of the JUnit spec for [**test suites**](https://github.com/nextest-rs/quick-junit/blob/main/src/report.rs#L167-L168), including [example](https://github.com/testmoapp/junitxml?tab=readme-ov-file#complete-junit-xml-example) and in the [Jest reporter](https://github.com/jest-community/jest-junit/blob/master/README.md) we use - Using the suite as a fallback should cover our bases and allow us to properly fallback for the sake of quarantining and dogfooding this - It's worth noting that everywhere I could find, `timestamp` refers to the start time. In theory if you intentionally ran 3 test runs in parallel (rather than jest retries' serial) you might get different results depending on finishing order. In theory, this is acceptable behavior since such a test would be considered flaky (eventually) anyway, but that leaves potential for follow-up work if/when we have a clear use case.
- Loading branch information