Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for sending build failure notifications to different CODEOWNERS owners than the origin build definition owners. #5181

Closed
konrad-jamrozik opened this issue Jan 20, 2023 · 2 comments
Assignees
Labels
Central-EngSys This issue is owned by the Engineering System team.

Comments

@konrad-jamrozik
Copy link
Contributor

konrad-jamrozik commented Jan 20, 2023

We interpret CODEOWNERS file to route build failure notifications, as described here. Specifically, if given CODEOWNERS path matches to build definition like ci.yml, the CODEOWNERS 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:

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 named PipelineOwner, e.g. /foo/PipelineOwner. This way if there is a CODEOWNERS path that matches to /foo/ci.yml it is not going to be used to determine where to route build failure notifications, but as a CODEOWNERS path that matches /foo/PipelineOwner, e.g. /foo/, will. You can find the details of this approach, and preceding discussion, here:

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:

We want to add a comment directive that instructs our CODEOWNERS interpreter to ignore given path for the purpose of determining who to notify about build failures from given build definition.

@ghost ghost added the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Jan 20, 2023
@konrad-jamrozik konrad-jamrozik self-assigned this Jan 20, 2023
@konrad-jamrozik konrad-jamrozik added Central-EngSys This issue is owned by the Engineering System team. and removed needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. labels Jan 20, 2023
@konrad-jamrozik konrad-jamrozik moved this from 🤔Triage to 📋Backlog in Azure SDK EngSys 🤖🧠 Jan 20, 2023
@konrad-jamrozik
Copy link
Contributor Author

@weshaggard @benbp instead of doing equivalent of this PR for other language repos:

I am going to work on implementing support for this work item, and then add relevant "ignore for purposes of build failure notification" comment directive to the /**/ci.yml and /**/tests.yml paths in the CODEOWNERS files. If you want to quickly see the contents of all the CODEOWNERS files, you can find links to them here:

@konrad-jamrozik konrad-jamrozik changed the title Add support for ignoring CODEOWNERS path for determining build failure notifications Add support for sending build failure notifications to different CODEOWNERS owners than the origin build definition owners. Jan 24, 2023
@konrad-jamrozik
Copy link
Contributor Author

This work item has been cancelled. For context, see this comment.

@github-project-automation github-project-automation bot moved this from 📋Backlog to 🎊Closed in Azure SDK EngSys 🤖🧠 Jan 25, 2023
@konrad-jamrozik konrad-jamrozik closed this as not planned Won't fix, can't repro, duplicate, stale Jan 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Central-EngSys This issue is owned by the Engineering System team.
Projects
None yet
Development

No branches or pull requests

1 participant