doc: improve onboarding instructions

joyeecheung · aduh95 · commit 3c6639e8ec4b · 2025-08-04T13:35:54.000+02:00
- Explains Jenkins CI - Document how to make the PR appear as "merged" if landed manually - Explain what other repositories are for. - Mention reliability repo and CI flakes PR-URL: #59159 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com> Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com> Reviewed-By: Chemi Atlow <chemi@atlow.co.il> Reviewed-By: Moshe Atlow <moshe@atlow.co.il> Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
diff --git a/onboarding.md b/onboarding.md
@@ -230,11 +230,13 @@ needs to be pointed out separately during the onboarding.
   labels. The `fast-track` label should cause the Node.js GitHub bot to post a
   comment in the pull request asking collaborators to approve the pull request
   by leaving a &#128077; reaction on the comment.
-* Optional: Run CI on the pull request. Use the `node-test-pull-request` CI
+* Optional: Run Jenkins CI on the pull request. Use the [`node-test-pull-request`][]
   task. As a convenience, you may apply the `request-ci` label to the pull
   request to have a GitHub Actions workflow start the Jenkins CI task for you.
 * After two Collaborator approvals for the change and two Collaborator approvals
-  for fast-tracking, land the PR.
+  for fast-tracking, land the PR. If you have started a full Jenkins CI, cancel it
+  from the Jenkins UI since the PR is a doc-only change and does not need
+  a full CI run, it is just run as an exercise.
 * If there are not enough approvals within a reasonable time, consider the
   single approval of the onboarding TSC member sufficient, and land the pull
   request.
@@ -245,6 +247,20 @@ needs to be pointed out separately during the onboarding.
   * [`core-validate-commit`][] automates the validation of commit messages.
     This will be run during `git node land --final` of the [`git-node`][]
     command.
+  * Normally you can just use the `commit-queue` label to have the
+    commit queued for landing by the Node.js GitHub bot. But as exercise it is
+    also useful to learn how to land commits manually in case the bot or the CI
+    is broken.
+* If you are landing the commit manually, to make it appear as "Merged" on GitHub,
+  after you prepare the landed commit on the local `main` branch, run this:
+
+  ```bash
+  git push --force-with-lease your-fork-remote HEAD:your-pr-branch # Update the PR branch in your fork.
+  git push upstream main  # Push the landed commit to the upstream main branch.
+  ```
+
+  GitHub will automatically detect that the PR branch is now identical to the
+  `main` branch and will mark the PR as "Merged".
 
 ## Final notes
 
@@ -253,11 +269,14 @@ needs to be pointed out separately during the onboarding.
 * Almost any mistake you could make can be fixed or reverted.
 * The existing collaborators trust you and are grateful for your help!
 * Other repositories:
-  * <https://github.com/nodejs/TSC>
-  * <https://github.com/nodejs/build>
-  * <https://github.com/nodejs/nodejs.org>
-  * <https://github.com/nodejs/Release>
-  * <https://github.com/nodejs/citgm>
+  * <https://github.com/nodejs/TSC>: Governance discussions and TSC votes
+  * <https://github.com/nodejs/build>: Build infrastructure discussions and CI issues
+  * <https://github.com/nodejs/nodejs.org>: The Node.js website and blog
+  * <https://github.com/nodejs/Release>: Release management and release planning
+  * <https://github.com/nodejs/citgm>: Tool for testing popular packages against Node.js changes
+  * <https://github.com/nodejs/admin>: Administrative issues and requests to changes in the Node.js
+    GitHub organization (e.g. creating new repositories, new teams, adding organization-wide tokens).
+  * <https://github.com/nodejs/moderation>: Requests to moderate comments or block spammers.
 * The OpenJS Foundation hosts regular summits for active contributors to the
   Node.js project, where we have face-to-face discussions about our work on the
   project. The Foundation has travel funds to cover [participants' expenses][]
@@ -266,6 +285,8 @@ needs to be pointed out separately during the onboarding.
   repository for details.
 * If you are interested in helping to fix coverity reports consider requesting
   access to the projects coverity project as outlined in [static-analysis][].
+* If you are interested in helping out with CI reliability, check out the
+  [reliability respository][] and [guide on how to deal with CI flakes][].
 
 [Code of Conduct]: https://github.com/nodejs/admin/blob/HEAD/CODE_OF_CONDUCT.md
 [Labels]: doc/contributing/collaborator-guide.md#labels
@@ -275,7 +296,10 @@ needs to be pointed out separately during the onboarding.
 [`author-ready`]: doc/contributing/collaborator-guide.md#author-ready-pull-requests
 [`core-validate-commit`]: https://github.com/nodejs/core-validate-commit
 [`git-node`]: https://github.com/nodejs/node-core-utils/blob/HEAD/docs/git-node.md
+[`node-test-pull-request`]: https://ci.nodejs.org/job/node-test-pull-request/
+[guide on how to deal with CI flakes]: https://github.com/nodejs/test?tab=readme-ov-file#protocols-in-improving-ci-reliability
 [participants' expenses]: https://github.com/openjs-foundation/cross-project-council/blob/main/community-fund/COMMUNITY_FUND_POLICY.md#community-fund-rules
+[reliability respository]: https://github.com/nodejs/reliability
 [set up the credentials]: https://github.com/nodejs/node-core-utils#setting-up-github-credentials
 [static-analysis]: doc/contributing/static-analysis.md
 [two-factor authentication]: https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/
