[live tests] test-resources.* file location and test parenting should be more flexible

[benbp]

Currently the test-resources.json, test-resources-pre.ps1 and test-resources-post.ps1 files are mapped 1:1 with all tests located within a service directory, and must be located within sdk/<service>/test-resources.*. This 1:1 mapping makes it harder to split up resource generation on a more granular basis, such as when there are multiple services per sdk (as is the case with storage, e.g. blob, batch, datalake, etc.).

We should perhaps support something like parameterized test-resources file locations or some sort of directory walking (look for files in sdk/<service>/<sub-service>/* first. Basically a way to better map resource provisioning to tests per-sdk, when they all exist within one pipeline definition.

[heaths]

Supporting nested file paths - much like git and other common file patterns - would be pretty easy to support. Start deep and work up, just like .gitignore files.

[heaths]

Another idea that was discussed was first deploy the general service template then, depending on its outputs, you could also go deeper. IMO, if there's no great reason to, not only would this take more time than a combined ARM template set, but would be more confusion for devs to use or probably us to support.

[benbp]

Related: Azure/azure-sdk-for-java#18773

[benbp]

@heaths I like the nested path, working up model. ServiceDirectory can already contain multiple directories (e.g. identity/some-sub-service) based on my reading of the code, but adding logic to search up to the base URI segment of the value could eliminate the need for manually specifying the service directory across all repos where there may be nested templates or not.

[heaths]

Yeah - the subdir resolution was intentional because, at one point in my design, the idea was to support sub-services (but not merging - which I like the idea of we're discussing here).

[github-actions]

Hi @benbp, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.