Update check-enforcer.md (#16)
Correct some formatting in the check enforcer markdown
This commit is contained in:
Родитель
d1e2349597
Коммит
1c861b5718
|
@ -22,9 +22,9 @@ Table of Contents
|
||||||
|
|
||||||
## Why did we create Check Enforcer?
|
## Why did we create Check Enforcer?
|
||||||
|
|
||||||
The Azure SDK team maintains reusable libraries that developers use to access Azure services. These libraries are grouped by together into a repository for each language/runtime. For example there is a repository for [Java](https://github.com/azure/azure-sdk-for-java), [.NET](https://github.com/azure/azure-sdk-for-net), [Python](https://github.com/azure/azure-sdk-for-python) and [JavaScript](https://github.com/azure/azure-sdk-for-javascript) - just to name a few.
|
The Azure SDK team maintains reusable libraries that developers use to access Azure services. These libraries are grouped together into a repository for each language/runtime. For example there are repositories for [Java](https://github.com/azure/azure-sdk-for-java), [.NET](https://github.com/azure/azure-sdk-for-net), [Python](https://github.com/azure/azure-sdk-for-python) and [JavaScript](https://github.com/azure/azure-sdk-for-javascript) - just to name a few.
|
||||||
|
|
||||||
Each repository contains a large number of separate libraries. Even though together these libraries constitute a single SDK, they ship separately on their own individual cadence as the underlying service evolves. As a result we have separate build and release pipelines for say the KeyVault and the Event Hubs libraries in each repository.
|
Each repository contains a large number of separate libraries. Even though together these libraries constitute a single SDK, they ship separately on their own individual cadence as the underlying service evolves. As a result, we have separate build and release pipelines for say the KeyVault and the Event Hubs libraries in each repository.
|
||||||
|
|
||||||
Whilst Checks in GitHub are awesome, one of the limitations when setting up required checks is that you cannot make them required for just one specific path. We don't want to build all libraries for every checkin (that would take a long time and needlessly block teams if other libraries were having build reliability issues) - so we needed a way to work around it.
|
Whilst Checks in GitHub are awesome, one of the limitations when setting up required checks is that you cannot make them required for just one specific path. We don't want to build all libraries for every checkin (that would take a long time and needlessly block teams if other libraries were having build reliability issues) - so we needed a way to work around it.
|
||||||
|
|
||||||
|
@ -44,13 +44,12 @@ Check Enforcer is our solution. We use the built-in triggering w/ path filter op
|
||||||
|
|
||||||
## Usage
|
## Usage
|
||||||
|
|
||||||
Check Enforcer runs within a github actions context, and triggers off two types of events: `check_suite completed` and `issue_comment created`.
|
Check Enforcer runs within a github actions context and is triggered by two types of events: `check_suite completed` and `issue_comment created`.
|
||||||
|
|
||||||
- `check_suite completed` behavior: When a pull request is created, github will show a pending status check for check enforcer based on the branch protection rule configured for the default branch (`main`). A check_suite is the github representation of all `check_runs` (e.g. pipeline jobs) associated with the head commit of the pull request branch. When all registered `check_runs` are completed, a `check_suite completed` event is triggered. The check enforcer github action will run at this time, evaluate the state of the `check_suite` and POST the corresponding state to the check enforcer `statuses` API endpoint for the pull request.
|
- `check_suite completed` behavior: When a pull request is created, github will show a pending status check for check enforcer based on the branch protection rule configured for the default branch (`main`). A check_suite is the github representation of all `check_runs` (e.g. pipeline jobs) associated with the head commit of the pull request branch. When all registered `check_runs` are completed, a `check_suite completed` event is triggered. The check enforcer github action will run at this time, evaluate the state of the `check_suite` and POST the corresponding state to the check enforcer `statuses` API endpoint for the pull request.
|
||||||
- `issue_comment created` behavior: When a comment is added to the pull request, check enforcer will check if that comment is a supported [command](#pr-comment-commands). If so, it will perform the corresponding behavior (reset, evaluate or override).
|
- `issue_comment created` behavior: When a comment is added to the pull request, check enforcer will check if that comment is a supported [command](#pr-comment-commands). If so, it will perform the corresponding behavior (reset, evaluate or override).
|
||||||
|
|
||||||
**NOTE:** Currently check enforcer will only handle events for check suites generated by the `Azure Pipelines` github
|
**NOTE:** Currently, check enforcer will only handle events for check suites generated by the `Azure Pipelines` github app.
|
||||||
app.
|
|
||||||
|
|
||||||
## Onboarding a New Service
|
## Onboarding a New Service
|
||||||
|
|
||||||
|
@ -84,7 +83,7 @@ If Check Enforcer appears to be stuck you can add a comment as follows to re-eva
|
||||||
/check-enforcer evaluate
|
/check-enforcer evaluate
|
||||||
```
|
```
|
||||||
|
|
||||||
From time to time Check Enforcer may be blocking a merge because no-check runs are appropriate for the PR, in these cases you can use the following command Check Enforcer rules and park the commit as successful:
|
From time to time, Check Enforcer may be blocking a merge because no-check runs are appropriate for the PR. In these cases, you can use the following command Check Enforcer rules and park the commit as successful:
|
||||||
|
|
||||||
```
|
```
|
||||||
/check-enforcer override
|
/check-enforcer override
|
||||||
|
|
Загрузка…
Ссылка в новой задаче