Add matrix for libraries tests on coreclr change

[jakobbotsch]

I tried initially to fill out the the remaining libraries test runs too (not just on coreclr changes), but I am unsure of a good way of presenting it. So this just adds the part I modified in #69180.

cc @agocke

[ghost]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I tried initially to fill out the the remaining libraries test runs too (not just on coreclr changes), but I am unsure of a good way of presenting it. So this just adds the part I modified in #69180.

cc @agocke

Author:	jakobbotsch
Assignees:	jakobbotsch
Labels:	area-Infrastructure
Milestone:	-

[danmoseley]

It's great we're documenting this as it's difficult to reverse engineer what the yaml does. Will we remember to keep this maintained? Another possibility perhaps is to store the table in the yamls themselves and link to those tables from here.

[jakobbotsch]

It's great we're documenting this as it's difficult to reverse engineer what the yaml does. Will we remember to keep this maintained? Another possibility perhaps is to store the table in the yamls themselves and link to those tables from here.

I'll defer to @agocke on this.

The dependencies here (which builds do we actually need for the tests we want to run) are complicated enough that I was considering autogenerating the entirety of runtime.yml based on a table where we could check off which configurations we wanted to run depending on which folders were changed. Then the table itself could be the source of truth.

I still think there's some resources to be saved by doing this and reevaluating the configurations in terms of build dependencies but I did not have more time to pursue it.

[agocke]

Another possibility perhaps is to store the table in the yamls themselves and link to those tables from here.

I'm perfectly fine with this.

The dependencies here (which builds do we actually need for the tests we want to run) are complicated enough that I was considering autogenerating the entirety of runtime.yml based on a table where we could check off which configurations we wanted to run depending on which folders were changed. Then the table itself could be the source of truth.

This would be great, but it definitely seems like a large amount of work.

My main goal was to have a single area of code where we could look for various versions and the intended matrix. Even incremental improvements here are great. My only caution with using the yml as the source of truth is that I'd like there to be one place in the YAML where we list all this stuff, instead of how it is right now where the info is in many different files.

[stephentoub]

@jakobbotsch, should this be merged? Closed?

[jakobbotsch]

I'll close this for now, I'm not sure the table is even up to date anymore.