-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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.
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
build: implement a Commit Queue in Actions #34112
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking on this thankless, unglamorous job, Matheus.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after fixing the md.
I thought I addressed all comments yesterday. Did I miss something? |
@mmarchini PTAL at github-actions warnings of |
I plan to land this late next week (probably next Friday). Want to wait a little more to see if we learn anything else from the |
fa9c3fc
to
09f8a36
Compare
Might as well land it tomorrow since we might change how the Jenkins starter works (#34707). I still think I'll update the docs in this PR to replace mentions of "pull_request event won't work" with "if we use pull_request_target and two actions run simultaneously the second one to finish will fail to push". |
This is a (still experimental) implementation of a Commit Queue on GitHub Actions, using labels and the scheduler event to land Pull Requests. It uses `node-core-utils` to validate Pull Requests and to prepare the commit message, and then it uses a GitHub personal token to push changes back to the repository. If the Queue fails to land a Pull Request, that PR will be removed from the queue and the `node-core-utils` output will be pasted in the Pull Request. An overview of the implementation is provided in doc/guides/commit-queue.md, as well as current limitations. Ref: https://github.com/mmarchini-oss/automated-merge-test Ref: nodejs/build#2201
09f8a36
to
d1f4de4
Compare
Does this validate that the cq label was added by someone with commit permissions? |
It works under the assumption that only folks with commit permission can add labels, which was true until a month or so ago when we introduced the triaging team :/ Nice catch, will update with this check. |
I actually think it would be helpful if triagers could kick off CQ, it’s just that their reviews shouldn’t count towards the PR being ready, right? |
This comment has been minimized.
This comment has been minimized.
Co-authored-by: Anna Henningsen <[email protected]>
wow! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is awesome, i'm really excited to see where this goes 🥳
this is super awesome @mmarchini. Incredible work, Mary. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looking forward to seeing this in action.
Comments are non-blocking.
1. The Pull Request must have only one commit | ||
2. A CI must've ran and succeeded since the last change on the PR | ||
3. A Collaborator must have approved the PR since the last change | ||
4. Only Jenkins CI is checked (Actions, V8 CI and CITGM are ignored) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Actions are checked now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not yet, I have a PR open for that
# TODO(mmarchini): install from npm after next ncu release is out | ||
npm install -g 'https://github.com/mmarchini/node-core-utils#commit-queue-branch' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we get a new version of node-core-utils published before landing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we get a new version before I land this I'll update here, otherwise I'll follow up with a PR to update it later
omg I just realized I made a huge mistake on my comment above. Triage team will be able to start Commit Queue, not CI (they already can start CI today :) ). So let me rephrase my question: should the triage team be allowed to start Commit Queue, which means they will be able to land pull requests? As @addaleax mentioned above, triage team will still not count towards reviews, and the Commit Queue runs all the necessary checks before landing (wait time, reviews, CI, etc). This might help offload some landing work from collaborators, which is good. OTOH it gives partial commit permission to a team separate from collaborators. So what do folks think? |
@mmarchini I didn’t even notice :) To be clear, I’m very much +1 on both. |
This is a (still experimental) implementation of a Commit Queue on GitHub Actions, using labels and the scheduler event to land Pull Requests. It uses `node-core-utils` to validate Pull Requests and to prepare the commit message, and then it uses a GitHub personal token to push changes back to the repository. If the Queue fails to land a Pull Request, that PR will be removed from the queue and the `node-core-utils` output will be pasted in the Pull Request. An overview of the implementation is provided in doc/guides/commit-queue.md, as well as current limitations. Ref: https://github.com/mmarchini-oss/automated-merge-test Ref: nodejs/build#2201 PR-URL: #34112 Refs: https://github.com/mmarchini-oss/automated-merge-test Refs: nodejs/build#2201 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Shelley Vohr <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Richard Lau <[email protected]>
Landed in a84716a 🎉 |
Guess I'll find out when someone uses it, but when this action is used, who/what shows up on the This is in no way opposition to this nor am I asking to be accommodated. Just curious what the change will look like. I am fully on Team Commit Queue. |
For now it will show "Node.js GitHub Bot" (https://github.com/nodejs/node/pull/34112/files#diff-21f285c740fafee2a921678194aef7abR39-R40). Totally feasible to change it to the collaborator who added the label though if we decide that adding the label will count as "active metrics". Another option is to keep committing as the bot but add |
This is a (still experimental) implementation of a Commit Queue on GitHub Actions, using labels and the scheduler event to land Pull Requests. It uses `node-core-utils` to validate Pull Requests and to prepare the commit message, and then it uses a GitHub personal token to push changes back to the repository. If the Queue fails to land a Pull Request, that PR will be removed from the queue and the `node-core-utils` output will be pasted in the Pull Request. An overview of the implementation is provided in doc/guides/commit-queue.md, as well as current limitations. Ref: https://github.com/mmarchini-oss/automated-merge-test Ref: nodejs/build#2201 PR-URL: #34112 Refs: https://github.com/mmarchini-oss/automated-merge-test Refs: nodejs/build#2201 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Shelley Vohr <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Richard Lau <[email protected]>
This is a (still experimental) implementation of a Commit Queue on GitHub Actions, using labels and the scheduler event to land Pull Requests. It uses `node-core-utils` to validate Pull Requests and to prepare the commit message, and then it uses a GitHub personal token to push changes back to the repository. If the Queue fails to land a Pull Request, that PR will be removed from the queue and the `node-core-utils` output will be pasted in the Pull Request. An overview of the implementation is provided in doc/guides/commit-queue.md, as well as current limitations. Ref: https://github.com/mmarchini-oss/automated-merge-test Ref: nodejs/build#2201 PR-URL: #34112 Refs: https://github.com/mmarchini-oss/automated-merge-test Refs: nodejs/build#2201 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Shelley Vohr <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Richard Lau <[email protected]>
This is a (still experimental) implementation of a Commit Queue on GitHub Actions, using labels and the scheduler event to land Pull Requests. It uses `node-core-utils` to validate Pull Requests and to prepare the commit message, and then it uses a GitHub personal token to push changes back to the repository. If the Queue fails to land a Pull Request, that PR will be removed from the queue and the `node-core-utils` output will be pasted in the Pull Request. An overview of the implementation is provided in doc/guides/commit-queue.md, as well as current limitations. Ref: https://github.com/mmarchini-oss/automated-merge-test Ref: nodejs/build#2201 PR-URL: #34112 Refs: https://github.com/mmarchini-oss/automated-merge-test Refs: nodejs/build#2201 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Shelley Vohr <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Richard Lau <[email protected]>
This is a (still experimental) implementation of a Commit Queue on GitHub Actions, using labels and the scheduler event to land Pull Requests. It uses `node-core-utils` to validate Pull Requests and to prepare the commit message, and then it uses a GitHub personal token to push changes back to the repository. If the Queue fails to land a Pull Request, that PR will be removed from the queue and the `node-core-utils` output will be pasted in the Pull Request. An overview of the implementation is provided in doc/guides/commit-queue.md, as well as current limitations. Ref: https://github.com/mmarchini-oss/automated-merge-test Ref: nodejs/build#2201 PR-URL: #34112 Refs: https://github.com/mmarchini-oss/automated-merge-test Refs: nodejs/build#2201 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Shelley Vohr <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Richard Lau <[email protected]>
This is a (still experimental) implementation of a Commit Queue on
GitHub Actions, using labels and the scheduler event to land Pull
Requests. It uses
node-core-utils
to validate Pull Requests and toprepare the commit message, and then it uses a GitHub personal token to
push changes back to the repository. If the Queue fails to land a Pull
Request, that PR will be removed from the queue and the
node-core-utils
output will be pasted in the Pull Request.An overview of the implementation is provided in
doc/guides/commit-queue.md, as well as current limitations.
Ref: https://github.com/mmarchini-oss/automated-merge-test
Ref: nodejs/build#2201
I've been testing this feature on https://github.com/mmarchini-oss/automated-merge-test and it works well for most general cases. If anyone wants to give it a try, let me know so I can add you to the repository.
Here's an example of the Action landing a Pull Request:
(mmarchini-oss/automated-merge-test#17)
And here's an example of the comment left by the Action when a PR fails to land:
(mmarchini-oss/automated-merge-test#54 (comment))
Requirements to land
GH_USER_NAME
,GH_USER_TOKEN
andJENKINS_TOKEN
secrets to this repository (or to the entire org, if we want this to work on forks such as quic and node-auto-test as well)commit-queue
andcommit-queue-failed
labels in this repositoryChecklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes