-
Notifications
You must be signed in to change notification settings - Fork 77
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
Auto-detect number of parts #317
Comments
This actually just broke our build. I'm not sure of the details, but short version is that CircleCI retries nodes if there was a problem with them. In this case CircleCI rebuilt one of the nodes, apparently after it had submitted the results, and that meant that there were 15 (3 test suites x 5 containers) instead of 12 (3 x 4) that was expected. From what I see in the source, the only place the number of parts is used is to throw the error. Why is that? test-reporter/cmd/sum-coverage.go Line 26 in 8a0c606
|
Hey @bmulholland 👋. I'm sorry this broke your build! Let me dig into this a little deeper and see what I can find out. |
Hey @bmulholland. Sorry for the delay in getting back to you! Would you be able to provide a little more information about how you're writing the partial test results and what filenames they end up in? Are you using the index/name of the container in some way? |
Yes, that's right. We've got three test suites, and each test suite is split across four containers. So I've named them Honestly, I'm tempted to just write a small script to count the number of matching files and then pass that in to the test reporter... but this seems like something that the test reporter should handle on its own! This is the only example of a tool I can think of that requires you to pass in both the files and the exact number of files - seems redundant? |
I was wondering about the same thing, so I just tried omitting the |
We have one part per test suite per container, currently adding up to 12 parts. If any of those parts doesn't get to the end of the build for any reason, the test reporter crashes because the number of parts was set wrong. This gives a false impression of why the build failed (because of codeclimate instead of the original issue). If the reporter could just count how many files apply, then there wouldn't be a mismatch in expectations and there would be no confusion about why a build failed.
The text was updated successfully, but these errors were encountered: