On 27 Jan 2026, at 17:40, Aaron Conole via dev wrote:
> While adding new code, we can sometimes miss whether there is sufficient > test case coverage that accommodates the new functionality. Additionally, > code that lacks sufficient test case coverage is ripe for new > contributors to find ways of delivering meaningful contributions to the > code base. > > Add a new CI job that executes the tests with code coverage and archives > the results. To help facilitate this, update the coverage check to also > add '-fprofile-update=atomic' (due to some code paths being > multi-threaded) and make the github job explicitly not optimize code. > The resulting jobs can be analyzed for more details offline due to the > archives. > > Signed-off-by: Aaron Conole <[email protected]> > --- Hi Aaron, Thanks for working on this. I’m a big fan of adding coverage testing, but I want to make sure we get the maximum benefit from the extra CI time this will consume. My main concern is that without a pass/fail threshold, the data might be ignored. Do you have a vision for how contributors would use these logs effectively, especially given GitHub's limited artifact retention? It would be nice if we could eventually get to a "Diff Coverage" report (highlighting only the new code), though I know that is technically complex with our current diff/patching setup (similar to clang-analyze). For now, do you think we should hold off on merging this until we can add some enforcement or clearer reporting? I’m worried about increasing the CI load without a guaranteed actionable outcome. //Eelco _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
