Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Data Collector misses tons of resources #8049
The datacollector code is filled with
Our primary use-case for datacollector is to get the data about child runcontexts we can't access from report handlers or event handlers (see #8044).
Please update datacollector to include nested resources, possibly with a config if necessary.
So #8063 is going this direction.
The question I've got is what the JSON output should look like? Right now in the action collection I've kept it flat and the wrapping resource appears after all the sub-resources. There's a single integer for how many nesting levels deep the resource is. That's the minimum viable product here most likely, makes it easy for consumers to just rip through the whole thing and not care about nesting at all as well (optimizing for the case where the user cares that there's a file resource on a given file but has no interest in how many levels deep inside of a resource it occurs).
I think the best choice would be to do something like
This would be useful to be able to debug weird problems, to figure out where two duplicate child-resources in different run contexts were coming from, etc...
I think it's not absolutely necessary to do it this way - your way will get us what we need at the moment. My concern is backcompat. If we do the less-expressive way now, changing it later is hard.