Using Shipshape (proto) for code coverage

[gluck]

Hi,

we're evaluating the use of shipshape Notes format for coverage information (in the context of Gerrit, like git-appraise is doing).
Would you have any recommendation as to which category (/subcategory) to use for that, and how to store the coverage info (e.g. fully covered/not covered/3 out of 4 branches covered) within a Note ?

I was think to use the "CodeCoverage" category (w/o subcategory), but for the additional info (coverage status, number of hits, number of branches, number of tested branches), what would you suggest ?

• encode them in the (textual) description
• use more_info / additional_data ?

(I didn't find any actual use of Shipshape for coverage, but was hoping you may have thought about it anyway)

Thanks.

[emsod]

Hi,

Sorry for the late reply.

From your description, CodeCoverage appears to be a good category name. If it makes sense to have subcategories sort of depends. Sometimes we use the category to indicate which the responsible tools is, for example, ExtendJ, and let the subcategory be the specific analysis, for instance, NullDereference.

From the screenshot on the thread (https://raw.githubusercontent.com/Ullink/gerrit-coverage-plugin/master/img/coverage_screen1.png), showing the orange part as a finding seems appropriate and it seems actionable (which is important from our experience). For findings like this one, it seems fine to put the data in the description field in the Notes proto. You probably want to keep it small. If you think something will become too big, you can use the more_info field to give a link to a longer description.

Let me know if I missed something.

[gluck]

Unfortunately there are more information to store than the description (line can be green/orange/red for fully-covered/partly/not-covered, plus for partial coverage we need to report the number of not-covered branches).

Ultimately that's just 3 numbers to store for each line, but I can't see this fit the current shipshape format.

Encoding that in the description (X/Y/Z) would be hack'ish (need to parse it back), but at the same time having to look up an extra link for each line seems way overkill.

Thanks for your time !

[clconway]

Some ad hoc encoding in the description is definitely the most expedient route. I think for the general case we probably need to support proto extensions or add a google.protobuf.Any field.