This document attempts to define a set of logical rules based on the existing Fabric Bot implementation. Rules are described based on their logical association; in some cases, these may need to be expanded into multiple physical rules due to how GitHub events and/or Actions work. Likewise, concepts and flow are intentionally kept abstract and do not intend to describe a specific implementation. An example of this is the different data integrations. Multiple data items may drive from a single source, but they constitute different logical concepts.
- Trigger: An event that occurs in GitHub to which automation should respond to.
- Target: An item in GitHub that can trigger an event. Generally, this will be an issue or pull request.
- Criteria: A set of evaluations performed for a trigger target that determines which actions, if any, result.
- Actions: A set of "things that happen" in response to a trigger. For example, adding a label to an issue.
- Textual content for comments generated by rules generally makes reference to existing content in the .NET ruleset. For brevity, these read similar to
Content from .NET rule #. These rule numbers can be viewed by loading the .NET repository into the Fabric Bot portal.
-
Service partners: Each partner team that owns packages in our repository will need to have an association tracking a service label to one or more GitHub handles. The contacts for service teams will follow the same pattern as the "Service Attention" process does today; it must be possible to assign a set of service owners that differs from the individuals assigned as pull request reviwers.
Example:
{ "label" : "Storage", "contacts" : ["@person1", "@person2"] } -
Azure SDK team owners: Each package in our repository that is owned by our team will need to have an association tracking a service label to one or more GitHub handles. This is an unofficial mapping that does not necessarily correlate to authoritative "Azure SDK Team" membership, such as that represented by our security groups or the "azure-sdk-team" GitHub team. That said, using one of these groups to validate membership on top of the label association would be just fine.
The set of owners responsible for triage for a given service may not be the same as those who should be tagged as pull request reviewers. It should not be assumed that triage owners can be correctly inferred from the existing path/label definitions in CODEOWNERS.
Example:
{ "label" : "Event Hubs", "contacts" : ["@jsquire"] } -
File paths: A service label may have one or more file paths relative to the repository structure associated with it.
Example:
{ "label" : "Tables", "paths" : ["/sdk/tables/Azure.Data.Tables", "/sdk/samples/some-table-sample"] }
This is a REST API that evaluates the content of an issue and attempts to predict a set of labels that should be applied to it. If a prediction is made with a reasonable level of confidence, the service will return exactly one service label and one category label. If confidence thresholds were not met for both label types, no labels are returned.
{
"issueNumber": 32227,
"title": "Move Snippet Generator to .NET 6",
"body": "The snippet generator tool currently targets netcoreapp3.1 which reaches end-of-life in December, 2022. The target framework should be updated to net6.0 and the associated Update-Snippet script should be updated to reference the new version.",
"issueUserLogin": "jsquire",
"repositoryName": "azure-sdk-for-net",
"repositoryOwnerName": "Azure"
}Predictions made
{
"labels": [
"Storage",
"Client"
]
}No predictions
{
"labels": []
}Today, this functionality exists as part of an Azure Function that hooks into our Event Hubs feed for GitHub events and operates independent of FabricBot and other automation. It will need to be revised to expose an API that can be called on demand from the actions-based rules, or we will need to determine a way to more directly integrate it into the new platform.
For the purposes of the rule definitions herein, it is assumed that this is a stand-alone service providing a REST API.