Add support for sending build failure notifications to different CODEOWNERS owners than the origin build definition owners. #5181
Labels
Central-EngSys
This issue is owned by the Engineering System team.
We interpret
CODEOWNERS
file to route build failure notifications, as described here. Specifically, if givenCODEOWNERS
path matches to build definition likeci.yml
, theCODEOWNERS
owners will be notified of build failures of this build definition.Because
CODEOWNERS
is also used to determine who is assigned to PR reviews, as a result, the set of PR reviewers for given build definition is the same set of people who get notified about that build definition build failures.However, some of the time we don't actually want that: we want for different people to review the given build definition changes than be notified of its build failures. For an example of this, see this comment and surrounding comments:
/**/ci.yml
and/**/tests.yml
azure-sdk-for-net#33595 (comment)This work is about adding this capability.
We will make the
notification-configuration
tool search for owners not of the pipeline definition file it originated from (e.g./foo/ci.yml
), but a made-up sibling file namedPipelineOwner
, e.g./foo/PipelineOwner
. This way if there is aCODEOWNERS
path that matches to/foo/ci.yml
it is not going to be used to determine where to route build failure notifications, but as aCODEOWNERS
path that matches/foo/PipelineOwner
, e.g./foo/
, will. You can find the details of this approach, and preceding discussion, here:/**/ci.yml
and/**/tests.yml
azure-sdk-for-net#33595 (comment)This work is to be picked up during the same time frame as:
Obsolete approach
Below is an obsolete approach which we rejected, per the discussion here:
/**/ci.yml
and/**/tests.yml
azure-sdk-for-net#33595 (comment)We want to add a comment directive that instructs ourCODEOWNERS
interpreter to ignore given path for the purpose of determining who to notify about build failures from given build definition.The text was updated successfully, but these errors were encountered: