|
|
|
|
|
|
by diggan
3005 days ago
|
|
|
This will get messy quickly if you have a PR that you are adding commits to and have a failure for each commit. This has the same problem as some code coverage solutions, they are spamming the PR with comments that are only important for a few moments, then they are just noise... Speaking about finding test failures quickly though, Jenkins and many others (except ALL the cloud/SaaS solutions?) actually parse test results via junit or similar to show you failures easily. I'm wondering why more SaaS don't do this? See an example here (for our js-ipfs project): https://ci.ipfs.team/blue/organizations/jenkins/IPFS%2Fjs-ip... It's so much easier to find test failures now and doesn't involve leaving a comment on the PR. It's simply two clicks to find this view from a PR (click the status message, click on "tests") |
|
|
re: parsing test results
CircleCI has been doing this for years. Not only does CircleCI read and store JUnit formatted test metadata but provides a dashboard called "Insights" to show this data overtime.
A Doc on collecting this data can be found here: https://circleci.com/docs/2.0/collect-test-data/
re: Code coverage spam
Thank you! I've often felt this way but never seen anyone else mention this. For many code coverage tools, you can integrate them at the GitHub point, which then gives you that "code coverage spam" or you can integrate it with a CI provider. This can simply fail a build if coverage drops. You can always have a status badge that shows coverage % in the readme as well.