1429461 - Use TUIDs in code coverage - requires defining, ingestion, and mapping

Status: NEW

(Testing :: Code Coverage, enhancement)

Description

[Kyle Lahnakoski [:ekyle]]

The TUID mapper is a project to map coverage from one revision to another.

Details are here: https://github.com/klahnakoski/ActiveData-ETL/blob/dev/docs/CodeCoverage%20TUID.md

Comment 1

[Marco Castelluccio [:marco]]

I'm still not convinced this is needed compared to what we already have with version control tools (namely, hg annotate).

Comment 2

[Kyle Lahnakoski [:ekyle]]

marco,

Yes, the Release Management requirements do not necessitate this technology. Instead, we are looking to solve a particular set of problems; namely coverage variability and per test coverage.

I have noticed a pattern in data management: When data is cleaned, it becomes more useful. Specifically: When data is explicitly annotated with context, it becomes more useful. I call this "context free" data because environmental context is not required to interpret it. 

Storing coverage in revision-free form makes it useful for solving the problems listed in the document, but I expect it will also be useful in ways we can not imagine yet.

Comment 3

[Marco Castelluccio [:marco]]

(In reply to Kyle Lahnakoski [:ekyle] from comment #2)
> marco,
> 
> Yes, the Release Management requirements do not necessitate this technology.
> Instead, we are looking to solve a particular set of problems; namely
> coverage variability and per test coverage.
> 
> I have noticed a pattern in data management: When data is cleaned, it
> becomes more useful. Specifically: When data is explicitly annotated with
> context, it becomes more useful. I call this "context free" data because
> environmental context is not required to interpret it. 
> 
> Storing coverage in revision-free form makes it useful for solving the
> problems listed in the document, but I expect it will also be useful in ways
> we can not imagine yet.

I wasn't talking about the release management requirements, but in general about the problems listed in the document.
They seem solvable with hg annotate: its output (revision + original line) seems to have exactly the same properties as a TUID to me:
 - If a new line is added, a new (revision + original line) is assigned.
 - If a line is removed, the (revision + original line) is retired.
 - If a line is changed, the old (revision + original line) is retired and a new one assigned.
 - If a line moves, because of changes above it, the (revision + original line) does not change.

That's why I wouldn't invest time on it unless we find a problem that can be solved with it but not with a normal annotate. After all, we have a lot of things to tackle, why choosing to tackle something that doesn't yet have clear value?

Comment 4

[Kyle Lahnakoski [:ekyle]]

I understand you better now. The TUID process is using hg annotate, so we are talking about the same annotation. This work is about maintaining a local cache so we minimize our hg calls as we annotate the coverage records.

Comment 5

[Marco Castelluccio [:marco]]

We can use the TUID service when we'll schedule Mac builds weekly, so we'll be able to map coverage on Mac from a given push to all other pushes of that same week.