Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always write test xml reports, and under dist/ #14806

Closed
benjyw opened this issue Mar 16, 2022 · 4 comments
Closed

Always write test xml reports, and under dist/ #14806

benjyw opened this issue Mar 16, 2022 · 4 comments
Assignees

Comments

@benjyw
Copy link
Contributor

benjyw commented Mar 16, 2022

Today we always generate and collect the xml reports for each test run (for pytest, junit, scalatest) but we discard them unless the user specifies --test-xml-dir=foo/bar, in which case we write them under /foo/bar.

This is at odds with how we write, say, coverage data, where the user asks for a report with, e.g., --test-use-coverage --coverage-py-report=json and then we pick the directory under dist/, ensuring no naming collisions.

This issue proposes that:

A) We write these reports at a subdir of our choosing, under dist/.
B) We always write them, since we always gather them.

One might quibble with B). Perhaps we want an option to turn this off, but in that case I propose not getting too clever - a single boolean flag to turn it off globally will suffice.

@benjyw benjyw self-assigned this Mar 16, 2022
@jsirois
Copy link
Contributor

jsirois commented Mar 16, 2022

In the interest of knowing why we diverge, the original PR #9594.

@Eric-Arellano
Copy link
Contributor

Both sound good to me, including a single global option to turn it off.

Do note that several users are using this current implementation in CI..so I recommend we respect the deprecation policy, even though that will be clunky to implement.

@benjyw
Copy link
Contributor Author

benjyw commented Mar 16, 2022

In the interest of knowing why we diverge, the original PR #9594.

Yeah, I think back then we didn't have a good sense of what any of this should look like in v2.

@benjyw
Copy link
Contributor Author

benjyw commented Mar 28, 2022

Closed in #14929

@benjyw benjyw closed this as completed Mar 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants