Commit 1a494d5
doc: standardize on _pull request_
Sometimes we capitalize _pull request_ and sometimes we don't.
Standardize on lowercase based on Microsoft Style Guide, Chicago Manual
of Style, and GitHub's own docs and UI.
Refs: https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
Refs: https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request
Refs: https://docs.microsoft.com/en-us/style-guide/capitalization
PR-URL: #39384
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Zeyu Yang <himself65@outlook.com>
Reviewed-By: Harshitha K P <harshitha014@gmail.com>
Reviewed-By: Zijian Liu <lxxyxzj@gmail.com>1 parent 4c93968 commit 1a494d5
6 files changed
Lines changed: 72 additions & 72 deletions
File tree
- doc/guides
- contributing
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -311,7 +311,7 @@ $ make test-only | |||
| 311 | 311 | ||
| 312 | 312 | At this point, you are ready to make code changes and re-run the tests. | |
| 313 | 313 | ||
| 314 | - If you are running tests before submitting a Pull Request, the recommended | ||
| 314 | + If you are running tests before submitting a pull request, the recommended | ||
| 315 | 315 | command is: | |
| 316 | 316 | ||
| 317 | 317 | ```console | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -488,7 +488,7 @@ The TSC serves as the final arbiter where required. | |||
| 488 | 488 | who wish to land their own pull requests will self-assign them. Sometimes, an | |
| 489 | 489 | author will delegate to someone else. If in doubt, ask the assignee whether | |
| 490 | 490 | it is okay to land. | |
| 491 | - 1. Never use GitHub's green ["Merge Pull Request"][] button. Reasons for not | ||
| 491 | + 1. Never use GitHub's green ["Merge pull request"][] button. Reasons for not | ||
| 492 | 492 | using the web interface button: | |
| 493 | 493 | * The "Create a merge commit" method will add an unnecessary merge commit. | |
| 494 | 494 | * The "Squash and merge" method will add metadata (the pull request #) to the | |
@@ -911,7 +911,7 @@ need to be attached anymore, as only important bugfixes will be included. | |||
| 911 | 911 | * `arm`, `mips`, `s390`, `ppc` | |
| 912 | 912 | * No `x86{_64}` label because it is the implied default | |
| 913 | 913 | ||
| 914 | - ["Merge Pull Request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github | ||
| 914 | + ["Merge pull request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github | ||
| 915 | 915 | [Deprecation]: https://en.wikipedia.org/wiki/Deprecation | |
| 916 | 916 | [SECURITY.md]: https://github.com/nodejs/node/blob/HEAD/SECURITY.md | |
| 917 | 917 | [Stability Index]: ../api/documentation.md#stability-index | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -2,12 +2,12 @@ | |||
| 2 | 2 | ||
| 3 | 3 | > Stability: 1 - Experimental | |
| 4 | 4 | ||
| 5 | - *tl;dr: You can land Pull Requests by adding the `commit-queue` label to it.* | ||
| 5 | + *tl;dr: You can land pull requests by adding the `commit-queue` label to it.* | ||
| 6 | 6 | ||
| 7 | 7 | Commit Queue is an experimental feature for the project which simplifies the | |
| 8 | 8 | landing process by automating it via GitHub Actions. With it, collaborators can | |
| 9 | - land Pull Requests by adding the `commit-queue` label to a PR. All | ||
| 10 | - checks will run via node-core-utils, and if the Pull Request is ready to land, | ||
| 9 | + land pull requests by adding the `commit-queue` label to a PR. All | ||
| 10 | + checks will run via node-core-utils, and if the pull request is ready to land, | ||
| 11 | 11 | the Action will rebase it and push to master. | |
| 12 | 12 | ||
| 13 | 13 | This document gives an overview of how the Commit Queue works, as well as | |
@@ -17,8 +17,8 @@ implementation details, reasoning for design choices, and current limitations. | |||
| 17 | 17 | ||
| 18 | 18 | From a high-level, the Commit Queue works as follow: | |
| 19 | 19 | ||
| 20 | - 1. Collaborators will add `commit-queue` label to Pull Requests ready to land | ||
| 21 | - 2. Every five minutes the queue will do the following for each Pull Request | ||
| 20 | + 1. Collaborators will add `commit-queue` label to pull requests ready to land | ||
| 21 | + 2. Every five minutes the queue will do the following for each pull request | ||
| 22 | 22 | with the label: | |
| 23 | 23 | 1. Check if the PR also has a `request-ci` label (if it has, skip this PR | |
| 24 | 24 | since it's pending a CI run) | |
@@ -40,10 +40,10 @@ From a high-level, the Commit Queue works as follow: | |||
| 40 | 40 | ## Current limitations | |
| 41 | 41 | ||
| 42 | 42 | The Commit Queue feature is still in early stages, and as such it might not | |
| 43 | - work for more complex Pull Requests. These are the currently known limitations | ||
| 43 | + work for more complex pull requests. These are the currently known limitations | ||
| 44 | 44 | of the commit queue: | |
| 45 | 45 | ||
| 46 | - 1. All commits in a Pull Request must either be following commit message | ||
| 46 | + 1. All commits in a pull request must either be following commit message | ||
| 47 | 47 | guidelines or be a valid [`fixup!`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupltcommitgt) | |
| 48 | 48 | commit that will be correctly handled by the [`--autosquash`](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---autosquash) | |
| 49 | 49 | option | |
@@ -73,7 +73,7 @@ reasons: | |||
| 73 | 73 | `node-core-utils` is configured with a personal token and | |
| 74 | 74 | a Jenkins token from | |
| 75 | 75 | [@nodejs-github-bot](https://github.com/nodejs/github-bot). | |
| 76 | - `octokit/graphql-action` is used to fetch all Pull Requests with the | ||
| 76 | + `octokit/graphql-action` is used to fetch all pull requests with the | ||
| 77 | 77 | `commit-queue` label. The output is a JSON payload, so `jq` is used to turn | |
| 78 | 78 | that into a list of PR ids we can pass as arguments to | |
| 79 | 79 | [`commit-queue.sh`](../../tools/actions/commit-queue.sh). | |
@@ -87,8 +87,8 @@ that into a list of PR ids we can pass as arguments to | |||
| 87 | 87 | 1. The repository owner | |
| 88 | 88 | 2. The repository name | |
| 89 | 89 | 3. The Action GITHUB_TOKEN | |
| 90 | - 4. Every positional argument starting at this one will be a Pull Request ID of | ||
| 91 | - a Pull Request with commit-queue set. | ||
| 90 | + 4. Every positional argument starting at this one will be a pull request ID of | ||
| 91 | + a pull request with commit-queue set. | ||
| 92 | 92 | ||
| 93 | 93 | The script will iterate over the pull requests. `ncu-ci` is used to check if | |
| 94 | 94 | the last CI is still pending, and calls to the GitHub API are used to check if | |
0 commit comments