Lines Matching refs: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)
44 ## Issues and pull requests
47 [TSC][]. Notify other qualified parties for more input on an issue or a pull
52 Always show courtesy to individuals submitting issues and pull requests. Be
56 For first-time contributors, check if the commit author is the same as the pull
57 request author. This way, once their pull request lands, GitHub will show them
61 ### Closing issues and pull requests
63 Collaborators can close any issue or pull request that is not relevant to the
64 future of the Node.js project. Where this is unclear, leave the issue or pull
66 evidence that the issue or pull request has relevance, close it. Remember that
67 issues and pull requests can always be re-opened if necessary.
69 ### Author ready pull requests
71 A pull request is _author ready_ when:
77 Please always add the `author ready` label to the pull request in that case.
80 ### Handling own pull requests
82 When you open a pull request, [start a CI](#testing-and-ci) right away. Later,
85 As soon as the pull request is ready to land, please do so. This allows other
86 collaborators to focus on other pull requests. If your pull request is not ready
87 to land but is [author ready](#author-ready-pull-requests), add the
88 `author ready` label. If you wish to land the pull request yourself, use the
100 * For any related pull requests, create an associated issue in the
102 pull request to the issue. Add screenshots of discussion from the pull request
105 pull request using Node.js (team) as the account organization.
106 * Open a new issue in the public repository with the title `FYI - pull request
108 > FYI @xxxx we asked GitHub to delete your pull request while we work on
115 Contributors propose modifications to Node.js using GitHub pull requests. This
116 includes modifications proposed by TSC members and other collaborators. A pull
121 At least two collaborators must approve a pull request before the pull request
122 lands. One collaborator approval is enough if the pull request has been open
125 Approving a pull request indicates that the collaborator accepts responsibility
130 In some cases, it might be necessary to summon a GitHub team to a pull request
134 If you are the first collaborator to approve a pull request that has no CI yet,
136 pull request creator pushed new code since the last CI run.
140 A pull request can land if it has the needed [approvals](#code-reviews),
144 requirements. If a pull request meets all requirements except the
146 [`author ready`](#author-ready-pull-requests) label.
150 Collaborators can object to a pull request by using the "Request
152 objection. Any pull request objection must include a clear reason for that
154 towards consensus about the direction of the pull request. Where possible,
176 Before landing pull requests, allow 48 hours for input from other collaborators.
177 Certain types of pull requests can be fast-tracked and can land after a shorter
182 * `good-first-issue` pull requests might also be suitable.
187 To propose fast-tracking a pull request, apply the `fast-track` label. Then add
191 fast-track the pull request in that case.
193 The pull request can be fast-tracked if two collaborators approve the
194 fast-tracking request. To land, the pull request itself still needs two
197 Collaborators can request fast-tracking of pull requests they did not author.
206 Do not land any pull requests without the necessary passing CI runs.
208 yellow) [Jenkins CI](https://ci.nodejs.org/) is also required if the pull
244 If there are GitHub Actions CI failures unrelated to the change in the pull
248 If there are Jenkins CI failures unrelated to the change in the pull request,
250 `node-test-pull-request` job. It will preserve all the green results from the
257 * [`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)
258 is the CI job to test pull requests. It runs the `build-ci` and `test-ci`
290 For pull requests, it will look like `refs/pull/PR_NUMBER/head`
291 (e.g. for pull request #42 -> `refs/pull/42/head`).
292 * `REBASE_ONTO`: Change that to `origin/master` so the pull request gets rebased
293 onto master. This can especially be important for pull requests that have been
301 Copy/paste the URL for the job into a comment in the pull request.
302 [`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)
305 The [`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)
306 CI job can be started by adding the `request-ci` label into the pull request.
308 the `node-test-pull-request` automatically. If the `github-actions bot`
334 For undocumented APIs that are public, open a pull request documenting the API.
384 metadata. Raise a pull request like any other change.
395 soon as possible. Link to the pull request that introduces the new core module
398 For pull requests introducing new core modules:
434 Apply the `notable change` label to all pull requests that introduce
463 as soon as possible. If possible, do it before the pull request adding the
466 Use the `notable-change` label on pull requests that add or change the
471 Collaborators can opt to elevate pull requests or issues to the [TSC][].
472 Do this if a pull request or issue:
485 ## Landing pull requests
487 1. Avoid landing pull requests that have someone else as an assignee. Authors
488 who wish to land their own pull requests will self-assign them. Sometimes, an
491 1. Never use GitHub's green ["Merge pull request"][] button. Reasons for not
494 * The "Squash and merge" method will add metadata (the pull request #) to the
495 commit title. If more than one author contributes to the pull request,
502 issues. Run a new CI any time someone pushes new code to the pull request.
508 For pull requests from first-time contributors, be
518 is enough to land a pull request. If you discover a problem when using
537 pull request rather than rely on `git-node`.
556 [CONTRIBUTING.md](./contributing/pull-requests.md#step-1-fork)):
566 $ curl -L https://github.com/nodejs/node/pull/xxx.patch | git am --whitespace=fix
574 $ curl -L https://github.com/nodejs/node/pull/xxx.patch | git am -3 --whitespace=fix
577 If the 3-way merge succeeds, check the results against the original pull
580 If the 3-way merge fails, then it is most likely that a conflicting pull request
655 * Required: A `PR-URL:` line that references the full GitHub URL of the pull
665 pull request.
678 Optional: For your own commits, force push the amended commit to the pull
680 --force-with-lease origin master:bugfix`. Don't close the pull request.
682 status rather than the red closed status. If you close the pull request
683 before GitHub adjusts its status, it will show up as a 0 commit pull
694 Close the pull request with a "Landed in `<commit hash>`" comment. Even if
695 your pull request shows the purple merged status,
712 hint: 'git pull ...') before pushing again.
717 To fix this, pull with rebase from upstream, run the tests again, and (if the
721 git pull upstream master --rebase
754 appropriate. If a change applies only to the LTS branch, open the pull request
764 When you send your pull request, please state if your change is breaking. Also
770 * `lts-watch-` labels are for pull requests to consider for landing in staging
774 * `land-on-` are for pull requests that should land in a future v*.x
778 Any collaborator can attach these labels to any pull request/issue. As commits
783 Attach the appropriate `lts-watch-` label to any pull request that
843 * `tsc-agenda`: Open issues and pull requests with this label will be added to
848 * `author-ready` - A pull request is _author ready_ when:
851 semver-major pull requests).
854 Please always add the `author ready` label to pull requests that qualify.
877 * Used by releasers to mark a pull request as scheduled for inclusion in an
879 * Applied to the original pull request for clean cherry-picks, to the backport
880 pull request otherwise
882 * Used to indicate that a pull request needs a manual backport to a branch in
884 * Typically applied by a releaser when the pull request does not apply cleanly
888 * Applied to pull requests for which a backport pull request has been merged
890 * Applied to pull requests which the Release working group should consider
914 ["Merge pull request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-req…
923 [commit message guidelines]: contributing/pull-requests.md#commit-message-guidelines