Add missing /sdk/<dir> rules

[konrad-jamrozik]

This PR adds missing /sdk/<dir>/ rules to CODEOWNERS. These dirs need assignment of appropriate owners. @pallavit @jsquire FYI.

This change was proposed here:

• Enable the new, regex-based, wildcard-supporting CODEOWNERS matcher azure-sdk-tools#5088 (comment)

Related work:

• Fix invalid paths in CODEOWNERS #33584
• Remove CODEOWNERS rules /**/ci.yml and /**/tests.yml #33595
• Implement CODEOWNERS file changes validation (gating), with baselining azure-sdk-tools#4859
• Enable the new, regex-based, wildcard-supporting CODEOWNERS matcher azure-sdk-tools#5088
• Add support for wildcard handling of file matching in codeowners library azure-sdk-tools#2770

[jsquire]

Things with sub-rules will supersede this, right? For example, I won't be pinged every time there's something from Text Analytics or Form Recognizer that comes through?

[weshaggard]

I think these are a set of directories that currently don't have owners and were covered by the /sdk/ pattern before. We should find the correct owners for these paths.

To answer your question exactly any patterns further down would override these but currently there aren't any for these paths.

[jsquire]

I'm not concerned with the paths themselves, but the sub-rules with owners below. For my example:

/sdk/cognitiveservices/textanalytics @someone @another

I just want to be sure that would override the top-level rule.

[weshaggard]

Those would definitely override these rules however there currently isn't an /sdk/cognitiveservices/ rule so things like /sdk/cognitiveservices/ci.yml would match against this pattern and that is the path used for pipeline notifications. So we should try to add the correct owners for that so they get notified of pipeline failures.

[pallavit]

What is the guidance if we have multiple partners in the same directory? Do we separate the ci pipelines? Do the service team work with the engsys team to separate them?

[weshaggard]

I think it depends on the teams. If we have multiple teams that we should consider the following:

• Should they be in the same service directory?
• Can they all be owners of a shared pipeline for the service directory if they should be together?
• If they should be in the same service directory but don't want to share ownership then we would need to split up the pipelines further perhaps to the package level. I would say this is the last resort, but it is possible.

[pallavit]

For a lot of these directories we only have track1 SDKs with minimal to 0 activity. So, I am not sure we have clear answers to these questions.

Also, last I heard we were trying to use a central db to keep ownerships current - is that still the plan? Is it happening along with these updates?

[weshaggard]

Yes we are planning to try and move to a central db that would sync owners but we are still a long way from getting that all figured out.

[konrad-jamrozik]

/check-enforcer override