My use case is using workflows (~7 builds) with one build consisting primarily of splitting rspec tests across a number of containers. At present, since timing data isn’t available, the split is often ending up with one container at 2 minutes vs. another at 7 minutes, which is obviously suboptimal.
Note that prior to using workflows, we were able to use
store_test_results and see the results affect future builds.
I did read in documentation that
store_test_results key is not supported in jobs run in workflows:
1) Are there plans to support it (or something equivalent?) eventually? If you can share any timing info, that’d be helpful.
2) Is there a workaround I can use at present to provide test timings to future builds of the same workflow (or individual build in a workflow)?
What I’ve tried:
- Using the key as is, like we did before transitioning to workflow. Doesn’t work, documented not to work. No surprise here.
- Using the documentation here: https://circleci.com/docs/1.0/test-metadata/#rspec - placing the results in the
$CIRCLE_TEST_REPORTS/rspec/rspec.xmlfile, then hoping it magically gets picked up. This isn’t Circle 1.0, so not surprised that this didn’t work either.
store_artifactsand pushing the file up. While visible on the UI in appropriate format (yay!), it doesn’t seem to influence timing on future builds. Also expected.
Any help would be greatly appreciated.