Add `git node staging` command #875

ruyadorno · 2024-11-27T17:37:59Z

Add a new git node staging command that automates cherry-picking commits into staging branches.

It works by cherry-picking all commits that have no conflicts and skipping any commits that have conflicts while automating the sending of GitHub PR interactions to request backport for these commits, sending a message to the original PR and properly labelling it.

Usage:

Fetches a commit list using branch-diff and automatically cherry-picks / skips commits based on whether or not they land cleanly:

  git node staging

Sets a custom reporter to be used at the end of the automated operation:

  git node staging --reporter=markdown

Limits to 10 the number of commits to be cherry-picked:

  git node staging --pagination=10

Defines the release line (usually this can be inferred from the ncu.branch value as it should not be required most of the time):

  git node staging --releaseLine=22

Automates the backport request message, this won't run any of the branch-diff or cherry-pick routines. Useful for when you removed a faulty commit from the branch and want to signal to PR author and collaborators that commit now needs backporting, just use its PR#:

  git node staging --backport=12345

The skipGH option avoids gh hitting API requests. As such it enables for running a local-only / dry-run if the releaser wants to validate the final result of the staging branch without having to incur on all the automated messages spamming the Pull Requests:

git node staging --skipGH

Report

A report is generated at the end of operations listing information on the commits that were successfully cherry picked and commits that failed to be cherry-picked due to conflicts.

Important

Below is a short example of how these reports look like. The following report was generated for an operation that was limited using --pagination=10

Cherry-pick Report

6 successfully cherry-picked commits:

a21be0294d0 build,win: enable pch for clang-cl windows, build, v8 engine, tools, needs-ci, gyp
c7f82ec9780 doc: fix the return type of outgoingMessage.setHeaders() http, doc, author ready
d8c552a060b doc: edit onboarding guide to clarify when mailmap addition is needed doc, author ready, commit-queue-squash
a5590083cdd node-api: add napi_create_buffer_from_arraybuffer method buffer, c++, node-api, needs-ci, commit-queue-squash
6c836aa97ee meta: bump step-security/harden-runner from 2.9.1 to 2.10.1 meta, dependencies, github_actions
47b6c6748ba meta: bump github/codeql-action from 3.26.6 to 3.26.10 meta, dependencies, github_actions

4 commits that failed to cherry-pick:

71785889c89 lib: prefer logical assignment lib / src, author ready, needs-ci
4988bb549e7 tools: enforce ordering of error codes in errors.md tools, errors, author ready, dont-land-on-v18.x, dont-land-on-v20.x
9f9069d3130 fs: fix linter issue fs, fast-track, author ready, needs-ci, commit-queue-squash
90f56dbad9c module: throw ERR_NO_TYPESCRIPT when compiled without amaro util, module, errors, author ready, needs-ci, strip-types

More

The automate cherry-pick logic also includes local persistency of the ongoing commit list, in case a fatal error happens during the command execution, it's possible to resume after cleaning up the git repo state by running git node staging again.

If no text is provided to `cli.stopSpinner` then it should allow for non-persistent usage of the spinner.

Added a `captureStderr` option to `lib/run.js` `runAsyncBase` method that allows for adding stderr information to thrown errors.

Add a new `git node staging` command that automates cherry-picking commits into staging branches. It works by cherry-picking all commits that have no conflicts and skipping any commits that have conflicts while automating the sending of GitHub PR interactions to request backport for these commits, sending a message to the original PR and properly labelling it. Usage: Fetches a commit list using `branch-diff` and automatically cherry-picks / skips commits based on whether or not they land cleanly: git node staging Sets a custom reporter at the end of the automated operation: git node staging --reporter=markdown Limits to 10 the number of commits to be cherry-picked: git node staging --pagination=10 Defines the release line (usually this can be inferred from the ncu.branch value os it should not be required most of the time): git node staging --releaseLine=22 Automates the backport request message, this won't run any of the `branch-diff` or cherry-pick routines. Useful for when you removed a faulty commit from the branch and want to signal to PR author and collaborators that commit now needs backporting, just use its PR#: git node staging --backport=12345 More: The automate cherry-pick logic also includes local persistency of the ongoing commit list, in case a fatal error happens during the command execution, it's possible to resume after cleaning up the git repo state by running `git node staging` again.

ruyadorno · 2024-11-27T17:50:10Z

When working on the v22 release, I did a progressive run of the automation using the --pagination option to ensure that the tooling was working as intended, as a result I ended up with multiple reports that I'm linking below for future reference:

These markdown format reports are way more useful when properly rendered on the GitHub UI or something similar. Right now the command is just printing this result to stdout but as you can imagine this opens the door to having a future GitHub action that either comments or stores this report somewhere, I'm very open to ideas on how to improve that next step of the automation.

richardlau · 2024-11-27T17:52:48Z

lib/staging.js

+    if (this.isLTS) {
+      excludeLabels.push('baking-for-lts');
+      const res = await fetch('https://nodejs.org/dist/index.json');
+      if (!res.ok) throw new Error('Failed to fetch', { cause: res });
+      const [latest] = await res.json();
+      // Assume Current branch matches tag with highest semver value.
+      const latestReleaseLine = semver.coerce(latest.version).major;
+      if (!validNumber(latestReleaseLine)) {
+        throw new Error('Could not determine latest release line');
+      }
+      comparisonBranch = `v${latestReleaseLine}.x`;


The latest current may not be the best thing to compare to. For example, if you were to take the latest v23.x today, that would be v23.3.0 which was only released one week ago and presumably commits would be identified that do not meet the usual "two weeks in a current release" (depending, of course, on when the planned date for the release being prepared is).

Right, we need a better way to handle that 2-weeks delay for sure! That said, for now I think it might still be usable as long as we put enough guardrails in the release docs.

btw I'm def falling for that rn with my current release but given that I postponed it to next week I don't think it's worth going back to remove all the v23.3.0 commits but it goes to say that you're definitely right that this is a concern in the current implementation.

targos · 2024-11-28T01:04:53Z

I understand why you are doing it but I'm afraid of the notification spamming that this generates when there are many conflicts. It's also actually not a good idea to ask for backports on most PRs because landing backports in the wrong order increases the risk of conflicts.

RafaelGSS · 2024-11-28T02:21:40Z

I understand why you are doing it but I'm afraid of the notification spamming that this generates when there are many conflicts. It's also actually not a good idea to ask for backports on most PRs because landing backports in the wrong order increases the risk of conflicts.

I was afraid of it too. Maybe collapse all the messages into a single issue and add the backport-requested label to each one that might reduce the spamming?

targos · 2024-11-28T11:32:26Z

I really like that! It would solve many problems:

No more spam
Single place to collaborate on backports
Encourage doing the backports in the correct order
More visibility, by having an open issue instead of comments on merged PRs

ruyadorno · 2024-11-28T14:13:23Z

Right, I agree that having a single place to manage all the backports has many benefits, I think a simple way to tweak the implementation is to use thegh cli to open a new issue with that markdown report in which the commits that failed to cherry-pick section is the list of commits that need backporting in their expected order. Then the releasers and any other collaborator could work on that.

That said, I still believe that automatically placing the label is a fundamental step that needs to be part of the logic here but we can remove the automatic-commenting to avoid spamming.

ruyadorno · 2024-11-28T14:23:20Z

@targos to reinforce on the idea here, my hope is that this is going to be a much more sane workflow for the releasers.

As anedoctal evidence, for the current release I'm working on I signed off for the day after running the script (which spammed a bunch of comments and added all the labels) and the next day when I woke up in the morning I noticed that @aduh95 jumped in and landed a dozen of the straightforward backports. This happened without any coordination but it does reinforces my believe that if we put a little bit more structure around the process we can have a workflow that is going to be way less demanding on a single releaser.

And of course this new workflow won't prevent the releaser themselves to go through the list of backport-requested commits on their own time and land the straighforward conflict resolutions.

targos · 2024-11-28T15:28:06Z

I agree with everything you said.

ruyadorno added 2 commits November 24, 2024 22:21

chore: stopping spinner with no text skips persist

03936ce

If no text is provided to `cli.stopSpinner` then it should allow for non-persistent usage of the spinner.

chore: add captureStderr option to runAsyncBase

01db083

Added a `captureStderr` option to `lib/run.js` `runAsyncBase` method that allows for adding stderr information to thrown errors.

ruyadorno mentioned this pull request Nov 27, 2024

tools: add release-helper nodejs/node#51916

Closed

ruyadorno force-pushed the add-git-node-staging-cmd branch from 4dfd7c2 to aa53a75 Compare November 27, 2024 17:41

ruyadorno requested a review from aduh95 November 27, 2024 17:52

richardlau reviewed Nov 27, 2024

View reviewed changes

ruyadorno requested review from RafaelGSS and marco-ippolito November 27, 2024 17:52

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add `git node staging` command #875

Add `git node staging` command #875

ruyadorno commented Nov 27, 2024 •

edited

Loading

ruyadorno commented Nov 27, 2024 •

edited

Loading

richardlau Nov 27, 2024 •

edited

Loading

ruyadorno Nov 27, 2024

targos commented Nov 28, 2024

RafaelGSS commented Nov 28, 2024

targos commented Nov 28, 2024 •

edited

Loading

ruyadorno commented Nov 28, 2024

ruyadorno commented Nov 28, 2024

targos commented Nov 28, 2024

Add git node staging command #875

Are you sure you want to change the base?

Add git node staging command #875

Conversation

ruyadorno commented Nov 27, 2024 • edited Loading

Usage:

Report

Cherry-pick Report

6 successfully cherry-picked commits:

4 commits that failed to cherry-pick:

More

ruyadorno commented Nov 27, 2024 • edited Loading

richardlau Nov 27, 2024 • edited Loading

Choose a reason for hiding this comment

ruyadorno Nov 27, 2024

Choose a reason for hiding this comment

targos commented Nov 28, 2024

RafaelGSS commented Nov 28, 2024

targos commented Nov 28, 2024 • edited Loading

ruyadorno commented Nov 28, 2024

ruyadorno commented Nov 28, 2024

targos commented Nov 28, 2024

Add `git node staging` command #875

Add `git node staging` command #875

ruyadorno commented Nov 27, 2024 •

edited

Loading

ruyadorno commented Nov 27, 2024 •

edited

Loading

richardlau Nov 27, 2024 •

edited

Loading

targos commented Nov 28, 2024 •

edited

Loading