|
1 | 1 | # prlint
|
2 | 2 |
|
3 |
| -A Github action that checks pull requests around PR titles, description and other metadata. |
| 3 | +This package includes a GitHub Action that does the following: |
| 4 | +- Checks pull requests around PR titles, description and other metadata. |
| 5 | +- Assesses whether or not the PR is ready for review and attaches the correct label to the PR. |
4 | 6 |
|
5 |
| -# Checks |
| 7 | +# Rules |
6 | 8 |
|
7 |
| -### Mandatory Changes |
| 9 | +The first part of the GitHub Action validates whether or not the pull request adheres |
| 10 | +(or has been exempted from) to the following rules: |
8 | 11 |
|
9 |
| -This check validates that the modified files in the PR follow these rules: |
10 |
| - |
11 |
| -1. `feat` requires a change to a `README.md`. |
12 |
| -2. `feat` requires a change to a unit test file and integration test files. |
13 |
| -3. `fix` requires a change to a unit test file and integration test files. |
| 12 | +1. `feat` requires a change to a `README.md` (exemption is the label `pr-linter/exempt-readme`). |
| 13 | +2. Both `feat` and `fix` PRs require a change to a unit test file and integration test files (exemption is the label `pr-linter/exempt-unit-test` or `pr-linter/exempt-integ-test`). |
14 | 14 | 4. `BREAKING CHANGE` section is formatted correctly, per the [conventional commits] spec.
|
15 | 15 | 5. No breaking changes announced for stable modules.
|
| 16 | +6. Title prefix and scope is formatted correctly. |
| 17 | +7. The PR is not opened from the main branch of the author's fork. |
| 18 | +8. Changes to the cli have been run through the test pipeline where cli integ tests are run (indicated by the label `pr-linter/cli-integ-tested`). |
| 19 | +9. No manual changes to `packages/aws-cdk-lib/region-info/build-tools/metadata.ts` file. |
16 | 20 |
|
17 | 21 | > These rules are currently hard coded, in the future, we should consider using [danger.js](https://danger.systems/js/).
|
18 | 22 |
|
19 | 23 | [conventional commits]: https://www.conventionalcommits.org
|
20 | 24 |
|
| 25 | +# Evaluation and Assigning Labels |
| 26 | + |
| 27 | +The GitHub Action also handles whether or not the PR is ready for review, and by whom. |
| 28 | +A PR is ready for review when: |
| 29 | + |
| 30 | +1. It is not a draft |
| 31 | +2. It does not have any merge conflicts |
| 32 | +3. The PR linter is not failing OR the user has requested an exemption (`pr-linter/exemption-requested`) |
| 33 | +4. A maintainer has not requested changes |
| 34 | +5. A maintainer has not approved |
| 35 | + |
| 36 | +If the PR is ready for review, we also differentiate whether or not it is ready for a |
| 37 | +maintainer review (`pr/needs-maintainer-review`) or if we are soliciting help from our |
| 38 | +pool of trusted reviewers (`pr/needs-community-review`). |
| 39 | + |
| 40 | +A PR is prioritized for core team review when: |
| 41 | + |
| 42 | +1. It links to a p1 issue |
| 43 | +2. It links to a p2 issue and has an approved community review |
| 44 | + |
| 45 | +Based on the above rules, prlint will apply the correct label `pr/needs-maintainer-review` or `pr/needs-community-review` |
| 46 | +to the PR. |
| 47 | + |
21 | 48 | # Installation
|
22 | 49 |
|
23 | 50 | ```console
|
|
0 commit comments