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

Support the file attribute under <testcase> #17

Open
wcedmisten-reify opened this issue Jun 27, 2023 · 5 comments
Open

Support the file attribute under <testcase> #17

wcedmisten-reify opened this issue Jun 27, 2023 · 5 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@wcedmisten-reify
Copy link

The CircleCI docs expect a file attribute under the <testcase> or <testsuite> tags to lookup test timings by filename.

https://circleci.com/docs/use-the-circleci-cli-to-split-tests/#junit-xml-reports

Although I can't find this mentioned anywhere in the Junit schemas linked in the README, would you consider supporting this in your plugin?

@alysbrooks
Copy link
Member

Hi @wcedmisten-reify, thanks for suggesting this.

So implementing this would allow clicking on a file name to see all the timing for that file? Am I understanding you (and the CircleCI docs) correctly? That definitely seems useful.

@wcedmisten-reify
Copy link
Author

I'm not sure if there are any UI changes related to this feature, but the main benefit is that CircleCI can parallelize the tests based on the total execution time of a file.

For example, suppose there are 3 files containing unit tests, A, B, and C. The combined execution time for the tests in file A take 2 minutes to run, and files B and C take 1 minute each. Let's say the CircleCI config is parallelized with 2 workers, then the optimal distribution is to run A on worker 1 and B and C on worker 2.

The problem is that currently CircleCI knows the timings at a test level, but it isn't able to link those timings back to the file containing each test. So the file attribute is needed to establish that linking.

Hope this helps provide more context!

@lambduhh
Copy link

Meowdy @wcedmisten-reify

Thanks for bringing this to our attention! I reviewed during triage and introducing the file attribute in our JUnit XML outputs could significantly benefit CircleCI users. This enhancement not only aims to speed up test runs but becomes high priority since it could also lead to cost savings by improving test parallelization efficiency.

Rationale: CircleCI calculates charges based on actual test run times, not the aggregate job time. Efficient parallelization means less idle time and, consequently, reduced costs for users with extensive test suites. This feature would enable CircleCI to allocate tests based on precise file execution times, optimizing resource use and decreasing overall test duration.

In short, by making this update, we're looking at faster CI builds and potential savings for our users on CircleCI. It’s a strategic improvement that aligns with our commitment to enhance user experience and operational efficiency.

I'm excited about the potential here and believe it deserves our immediate attention. Changing status to "candidate" and updating to "high" priority.

References:
https://circleci.com/docs/parallelism-faster-jobs/

@lambduhh lambduhh added the help wanted Extra attention is needed label Mar 13, 2024
@lambduhh lambduhh moved this from Triage to Candidate in Lambda Island Open Source Mar 13, 2024
@wcedmisten-reify
Copy link
Author

It looks like there is already a flag that addresses this issue: --junit-xml-add-location-metadata

With it, I was able to get CircleCI test splitting working as expected (although I did need a hacky sed command to convert the absolute paths to relative ones in order for CircleCI to recognize the timing data).

Is there a reason this flag isn't enabled by default? I would propose enabling it unless there are serious objections to that behavior

@nnichols
Copy link
Contributor

nnichols commented Dec 5, 2024

I updated the linked PR to add a new flag to switch between relative/absolute pathing: --junit-xml-use-relative-path-in-location. (Biasing towards backwards compatibility in case different CI Platforms have different pathing expectations).

I don't have a dog in the race for enabling --junit-xml-add-location-metadata by default or not. I'll happily defer to the maintainers on that one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
Status: Candidate
Development

No branches or pull requests

4 participants