Lines Matching full:pull
5 * [Issues and pull requests](#issues-and-pull-requests)
7 * [Closing issues and pull requests](#closing-issues-and-pull-requests)
8 * [Author ready pull requests](#author-ready-pull-requests)
9 * [Handling own pull requests](#handling-own-pull-requests)
28 * [Landing pull requests](#landing-pull-requests)
45 ## Issues and pull requests
48 [TSC][]. Notify other qualified parties for more input on an issue or a pull
53 Always show courtesy to individuals submitting issues and pull requests. Be
57 For first-time contributors, check if the commit author is the same as the pull
58 request author. This way, once their pull request lands, GitHub will show them
62 ### Closing issues and pull requests
64 Collaborators can close any issue or pull request that is not relevant to the
65 future of the Node.js project. Where this is unclear, leave the issue or pull
67 evidence that the issue or pull request has relevance, close it. Remember that
68 issues and pull requests can always be re-opened if necessary.
70 ### Author ready pull requests
72 A pull request is _author ready_ when:
78 Please always add the `author ready` label to the pull request in that case.
81 ### Handling own pull requests
83 When you open a pull request, [start a CI](#testing-and-ci) right away. Later,
86 As soon as the pull request is ready to land, please do so. This allows other
87 collaborators to focus on other pull requests. If your pull request is not ready
88 to land but is [author ready](#author-ready-pull-requests), add the
89 `author ready` label. If you wish to land the pull request yourself, use the
101 * For any related pull requests, create an associated issue in the
103 pull request to the issue. Add screenshots of discussion from the pull request
106 pull request using Node.js (team) as the account organization.
107 * Open a new issue in the public repository with the title `FYI - pull request
109 > FYI @xxxx we asked GitHub to delete your pull request while we work on
116 Contributors propose modifications to Node.js using GitHub pull requests. This
117 includes modifications proposed by TSC members and other collaborators. A pull
122 At least two collaborators must approve a pull request before the pull request
123 lands. One collaborator approval is enough if the pull request has been open
126 Approving a pull request indicates that the collaborator accepts responsibility
131 In some cases, it might be necessary to summon a GitHub team to a pull request
135 If you are the first collaborator to approve a pull request that has no CI yet,
137 pull request creator pushed new code since the last CI run.
141 A pull request can land if it has the needed [approvals](#code-reviews),
145 requirements. If a pull request meets all requirements except the
147 [`author ready`](#author-ready-pull-requests) label.
151 Collaborators can object to a pull request by using the "Request
153 objection. Any pull request objection must include a clear reason for that
155 towards consensus about the direction of the pull request. Where possible,
164 Pull requests with outstanding objections must remain open until all
177 Before landing pull requests, allow 48 hours for input from other collaborators.
178 Certain types of pull requests can be fast-tracked and can land after a shorter
183 * `good-first-issue` pull requests might also be suitable.
188 To propose fast-tracking a pull request, apply the `fast-track` label. Then a
192 fast-track the pull request in that case.
194 The pull request can be fast-tracked if two collaborators approve the
195 fast-tracking request. To land, the pull request itself still needs two
198 Collaborators can request fast-tracking of pull requests they did not author.
207 Do not land any pull requests without the necessary passing CI runs.
209 yellow) [Jenkins CI](https://ci.nodejs.org/) is also required if the pull
245 If there are GitHub Actions CI failures unrelated to the change in the pull
249 If there are Jenkins CI failures unrelated to the change in the pull request,
251 `node-test-pull-request` job. It will preserve all the green results from the
256 If new commits are pushed to the pull request branch after the latest Jenkins
258 the left sidebar, or by adding the `request-ci` label to the pull request.
262 * [`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)
263 is the CI job to test pull requests. It runs the `build-ci` and `test-ci`
295 For pull requests, it will look like `refs/pull/PR_NUMBER/head`
296 (e.g. for pull request #42 -> `refs/pull/42/head`).
297 * `REBASE_ONTO`: Change that to `origin/main` so the pull request gets rebased
298 onto `main`. This can especially be important for pull requests that have been
306 Copy/paste the URL for the job into a comment in the pull request.
307 [`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)
310 The [`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)
311 CI job can be started by adding the `request-ci` label into the pull request.
313 the `node-test-pull-request` automatically. If the `github-actions bot`
339 For undocumented APIs that are public, open a pull request documenting the API.
407 metadata. Raise a pull request like any other change.
419 a placeholder in the module registry as soon as possible. Link to the pull
429 For pull requests introducing new core modules:
465 Apply the `notable-change` label to all pull requests that introduce
494 as soon as possible. If possible, do it before the pull request adding the
497 Use the `notable-change` label on pull requests that add or change the
502 Collaborators can opt to elevate pull requests or issues to the [TSC][].
503 Do this if a pull request or issue:
516 ## Landing pull requests
518 1. Avoid landing pull requests that have someone else as an assignee. Authors
519 who wish to land their own pull requests will self-assign them. Sometimes, an
522 2. Never use GitHub's green ["Merge pull request"][] button. Reasons for not
525 * The "Squash and merge" method will add metadata (the pull request #) to the
526 commit title. If more than one author contributes to the pull request,
533 issues. Run a new CI any time someone pushes new code to the pull request.
539 For pull requests from first-time contributors, be
543 If a pull request contains more than one commit, it can be landed either by
545 Generally, a collaborator should land a pull request by squashing. If a pull
559 is enough to land a pull request. If you discover a problem when using
578 pull request rather than rely on `git-node`.
597 [CONTRIBUTING.md](./pull-requests.md#step-1-fork)):
607 $ curl -L https://github.com/nodejs/node/pull/xxx.patch | git am --whitespace=fix
615 $ curl -L https://github.com/nodejs/node/pull/xxx.patch | git am -3 --whitespace=fix
618 If the 3-way merge succeeds, check the results against the original pull
621 If the 3-way merge fails, then it is most likely that a conflicting pull request
696 * Required: A `PR-URL:` line that references the full GitHub URL of the pull
706 pull request.
719 Optional: For your own commits, force push the amended commit to the pull
721 `git push --force-with-lease origin main:bugfix`. Don't close the pull
723 merged status rather than the red closed status. If you close the pull request
724 before GitHub adjusts its status, it will show up as a 0 commit pull
735 Close the pull request with a "Landed in `<commit hash>`" comment. Even if
736 your pull request shows the purple merged status,
753 hint: 'git pull ...') before pushing again.
758 To fix this, pull with rebase from upstream, run the tests again, and (if the
762 git pull upstream main --rebase
795 appropriate. If a change applies only to the LTS branch, open the pull request
805 When you send your pull request, please state if your change is breaking. Also
811 * `lts-watch-` labels are for pull requests to consider for landing in staging
815 * `land-on-` are for pull requests that should land in a future v\*.x
819 Any collaborator can attach these labels to any pull request/issue. As commits
824 Attach the appropriate `lts-watch-` label to any pull request that
884 * `tsc-agenda`: Open issues and pull requests with this label will be added to
889 * `author-ready` - A pull request is _author ready_ when:
892 semver-major pull requests).
895 Please always add the `author ready` label to pull requests that qualify.
918 * Used by releasers to mark a pull request as scheduled for inclusion in an
920 * Applied to the original pull request for clean cherry-picks, to the backport
921 pull request otherwise
923 * Used to indicate that a pull request needs a manual backport to a branch in
925 * Typically applied by a releaser when the pull request does not apply cleanly
929 * Applied to pull requests for which a backport pull request has been merged
931 * Applied to pull requests which the Release working group should consider
955 ["Merge pull request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-req…
964 [commit message guidelines]: pull-requests.md#commit-message-guidelines