GP Saggese

The approach should be similar to `--update_outcomes` where all the global cache mode is switched to UPDATE and cache is updated. All the code that touches the cache then refreshes...

> Got it, I have a few questions regarding the use cases of the cache: 1. Are we using the cache file solely for testing purposes? 2. If it’s only...

1 and 2, good point. - There should be a cache for the unit tests (which we check in), one for local execution (specific of a user, not shared, etc)...

I've done the reviewed for #788. Can we merge it? Then we can start using the entire system.

Interesting progress. My mental plan was simpler than this. E.g. - create a function that transforms a command line to be run inside Docker to track coverage - run the...

@madhurlak0810 I've posted the notes from our link here https://docs.google.com/document/d/1xPgQ2tWXQuVWKkGVONjOGd5j14mXSmGeY_4d1_sGzAE/edit?tab=t.v5h95jvu3hwe#heading=h.j6kcs1n3f3uz Let's do baby step, like an example of a totally hacked prototype to show that the approach is clear and...

Ok so what we have found out is that there is a native mechanism for multiple processes (which is our case for when we do a system call) https://coverage.readthedocs.io/en/7.8.0/subprocess.html For...

What do you mean by 1. Detect docker run? As to 2. we generate that automatically. If you have doubts a draft PR with a "prototype" is best, rather then...

I'm not sure this matches my mental model. The design principle is that the caller knows everything; the caller just does what it's told to do. - If the caller...

> 2. For the MVP I just want to clarify some things: > Just to clarify: if caller is active, we should ensure every Docker image installs the coverage package...