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.

Sign up for GitHub

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

doc: standardize on _pull request_ #39384

Closed
wants to merge 1 commit into from
Closed

doc: standardize on _pull request_ #39384

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion BUILDING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -305,7 +305,7 @@ $ make test-only

At this point, you are ready to make code changes and re-run the tests.

If you are running tests before submitting a Pull Request, the recommended
If you are running tests before submitting a pull request, the recommended
command is:

```console
Expand Down
4 changes: 2 additions & 2 deletions doc/guides/collaborator-guide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -488,7 +488,7 @@ The TSC serves as the final arbiter where required.
who wish to land their own pull requests will self-assign them. Sometimes, an
author will delegate to someone else. If in doubt, ask the assignee whether
it is okay to land.
1. Never use GitHub's green ["Merge Pull Request"][] button. Reasons for not
1. Never use GitHub's green ["Merge pull request"][] button. Reasons for not
using the web interface button:
* The "Create a merge commit" method will add an unnecessary merge commit.
* The "Squash and merge" method will add metadata (the pull request #) to the
Expand Down Expand Up @@ -911,7 +911,7 @@ need to be attached anymore, as only important bugfixes will be included.
* `arm`, `mips`, `s390`, `ppc`
* No `x86{_64}` label because it is the implied default

["Merge Pull Request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github
["Merge pull request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github
[Deprecation]: https://en.wikipedia.org/wiki/Deprecation
[SECURITY.md]: https://github.com/nodejs/node/blob/HEAD/SECURITY.md
[Stability Index]: ../api/documentation.md#stability-index
Expand Down
20 changes: 10 additions & 10 deletions doc/guides/commit-queue.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,12 +2,12 @@

> Stability: 1 - Experimental

*tl;dr: You can land Pull Requests by adding the `commit-queue` label to it.*
*tl;dr: You can land pull requests by adding the `commit-queue` label to it.*

Commit Queue is an experimental feature for the project which simplifies the
landing process by automating it via GitHub Actions. With it, collaborators can
land Pull Requests by adding the `commit-queue` label to a PR. All
checks will run via node-core-utils, and if the Pull Request is ready to land,
land pull requests by adding the `commit-queue` label to a PR. All
checks will run via node-core-utils, and if the pull request is ready to land,
the Action will rebase it and push to master.

This document gives an overview of how the Commit Queue works, as well as
Expand All @@ -17,8 +17,8 @@ implementation details, reasoning for design choices, and current limitations.

From a high-level, the Commit Queue works as follow:

1. Collaborators will add `commit-queue` label to Pull Requests ready to land
2. Every five minutes the queue will do the following for each Pull Request
1. Collaborators will add `commit-queue` label to pull requests ready to land
2. Every five minutes the queue will do the following for each pull request
with the label:
1. Check if the PR also has a `request-ci` label (if it has, skip this PR
since it's pending a CI run)
Expand All @@ -40,10 +40,10 @@ From a high-level, the Commit Queue works as follow:
## Current limitations

The Commit Queue feature is still in early stages, and as such it might not
work for more complex Pull Requests. These are the currently known limitations
work for more complex pull requests. These are the currently known limitations
of the commit queue:

1. All commits in a Pull Request must either be following commit message
1. All commits in a pull request must either be following commit message
guidelines or be a valid [`fixup!`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupltcommitgt)
commit that will be correctly handled by the [`--autosquash`](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---autosquash)
option
Expand Down Expand Up @@ -73,7 +73,7 @@ reasons:
`node-core-utils` is configured with a personal token and
a Jenkins token from
[@nodejs-github-bot](https://github.com/nodejs/github-bot).
`octokit/graphql-action` is used to fetch all Pull Requests with the
`octokit/graphql-action` is used to fetch all pull requests with the
`commit-queue` label. The output is a JSON payload, so `jq` is used to turn
that into a list of PR ids we can pass as arguments to
[`commit-queue.sh`](../../tools/actions/commit-queue.sh).
Expand All @@ -87,8 +87,8 @@ that into a list of PR ids we can pass as arguments to
1. The repository owner
2. The repository name
3. The Action GITHUB_TOKEN
4. Every positional argument starting at this one will be a Pull Request ID of
a Pull Request with commit-queue set.
4. Every positional argument starting at this one will be a pull request ID of
a pull request with commit-queue set.

The script will iterate over the pull requests. `ncu-ci` is used to check if
the last CI is still pending, and calls to the GitHub API are used to check if
Expand Down
Loading