| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
1 parent 753033c commit be4e7de
2 files changed
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -48,9 +48,7 @@ jobs: | |||
| 48 | 48 | fast_track_prs=$(list_prs \ | |
| 49 | 49 | --label 'fast-track' \ | |
| 50 | 50 | --search "-label:blocked") | |
| 51 | - queued_prs=$(list_prs \ | ||
| 52 | - --search "-label:blocked") | ||
| 53 | - candidates=$(printf '%s %s %s\n' "$aged_prs" "$fast_track_prs" "$queued_prs" | | ||
| 51 | + candidates=$(printf '%s %s\n' "$fast_track_prs" "$aged_prs" | | ||
| 54 | 52 | jq -r -s 'reduce .[] as $pr ([]; if index($pr) then . else . + [$pr] end) | join(" ")') | |
| 55 | 53 | echo "candidates=$candidates" >> "$GITHUB_OUTPUT" | |
| 56 | 54 | env: | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -20,32 +20,34 @@ From a high-level, the Commit Queue works as follows: | |||
| 20 | 20 | ||
| 21 | 21 | 1. Collaborators will add `commit-queue` label to pull requests they want the | |
| 22 | 22 | queue to land. The label can be added before the pull request has completed | |
| 23 | - its wait time, or before requested CI has finished. Required approvals must | ||
| 24 | - already be in place. The commit queue does not request CI on its own. | ||
| 23 | + its wait time. Required approvals must already be in place, and any required | ||
| 24 | + CI must have completed successfully. The commit queue does not request CI on | ||
| 25 | + its own. | ||
| 25 | 26 | 2. On each scheduled run, the queue builds a candidate list from open pull | |
| 26 | - requests with the `commit-queue` label and without the `blocked` label. The | ||
| 27 | - workflow uses a five-minute cron, but GitHub Actions scheduled workflows are | ||
| 28 | - not guaranteed to run exactly every five minutes. For each candidate, the | ||
| 29 | - queue will: | ||
| 27 | + requests with the `commit-queue` label and without the `blocked` label. A | ||
| 28 | + candidate must also either have been created at least two days earlier or | ||
| 29 | + have the `fast-track` label. Other labeled pull requests retain the label | ||
| 30 | + until they become old enough or are fast-tracked. The workflow uses a | ||
| 31 | + five-minute cron, but GitHub Actions scheduled workflows are not guaranteed | ||
| 32 | + to run exactly every five minutes. For each candidate, the queue will: | ||
| 30 | 33 | 1. In the landing job, install and configure `@node-core/utils`, then run a | |
| 31 | 34 | metadata-only readiness check without checking out the repository | |
| 32 | 35 | 2. If the metadata check exits with a deferrable readiness code, meaning | |
| 33 | 36 | the PR is only blocked on wait time, keep the `commit-queue` label and | |
| 34 | 37 | skip this PR until a later queue run | |
| 35 | - 3. Check if the PR also has a `request-ci` label (if it has, skip this PR | ||
| 36 | - since it's pending a CI run) | ||
| 37 | - 4. Check whether GitHub checks are still running (if they are, skip this PR) | ||
| 38 | - 5. Remove the `commit-queue` label and run `git node land` | ||
| 39 | - 6. If it fails: | ||
| 40 | - 1. Add the `commit-queue-failed` label to the PR | ||
| 38 | + 3. Run `git node land` for ready PRs and PRs with hard or mixed readiness | ||
| 39 | + failures, keeping the `commit-queue` label in place during the attempt | ||
| 40 | + 4. If it fails: | ||
| 41 | + 1. Replace the `commit-queue` label with the `commit-queue-failed` label | ||
| 41 | 42 | 2. Leave a comment on the PR with the output from `git node land` | |
| 42 | 43 | 3. Abort the `git node land` session. If the abort succeeds, continue to | |
| 43 | 44 | the next PR; otherwise, stop the queue in an unknown state | |
| 44 | - 7. If it succeeds: | ||
| 45 | + 5. If it succeeds: | ||
| 45 | 46 | 1. Push or merge the changes into nodejs/node | |
| 46 | 47 | 2. Leave a comment on the PR with `Landed in ...` | |
| 47 | 48 | 3. Close the PR | |
| 48 | - 4. Go to next PR in the queue | ||
| 49 | + 4. Remove the `commit-queue` label | ||
| 50 | + 5. Go to next PR in the queue | ||
| 49 | 51 | ||
| 50 | 52 | To make the Commit Queue squash all the commits of a pull request into the | |
| 51 | 53 | first one, add the `commit-queue-squash` label. | |
@@ -94,11 +96,11 @@ reasons: | |||
| 94 | 96 | without rebasing them first. | |
| 95 | 97 | ||
| 96 | 98 | The workflow starts with a small candidate job that uses GitHub CLI to fetch | |
| 97 | - pull requests with the `commit-queue` label. It first fetches the same | ||
| 98 | - age-based and fast-track buckets the queue used before accepting early queue | ||
| 99 | - requests, then fetches the broader queue and de-duplicates the result. This | ||
| 100 | - keeps not-yet-ready PRs from crowding out PRs that the previous query would | ||
| 101 | - have selected if GitHub paginates or caps a query result. | ||
| 99 | + open pull requests with the `commit-queue` label and without the `blocked` | ||
| 100 | + label. It fetches two buckets: pull requests created at least two days earlier | ||
| 101 | + and pull requests with the `fast-track` label. The job de-duplicates the | ||
| 102 | + buckets before passing the candidates to the landing job. Pull requests in | ||
| 103 | + neither bucket remain labeled but are not processed during that run. | ||
| 102 | 104 | ||
| 103 | 105 | If there are candidate PRs, the landing job installs and configures | |
| 104 | 106 | `@node-core/utils` once with a personal token and a Jenkins token from | |
@@ -123,9 +125,10 @@ states. Unknown filter failures fail the workflow before starting the landing | |||
| 123 | 125 | script and leave PR labels unchanged so the queue can retry on a later | |
| 124 | 126 | scheduled run. PRs passed through with exit code `40`-`49` continue through | |
| 125 | 127 | `commit-queue.sh`. The workflow checks out the repository only when at least | |
| 126 | - one PR remains after filtering. The script still applies its existing | ||
| 127 | - `request-ci` and pending-check deferrals before removing the queue label and | ||
| 128 | - reporting a hard failure. | ||
| 128 | + one PR remains after filtering. The script does not separately skip PRs with a | ||
| 129 | + `request-ci` label or pending GitHub checks. Instead, `git node land` performs | ||
| 130 | + the landing checks and the script reports any failure through the normal queue | ||
| 131 | + failure path. | ||
| 129 | 132 | ||
| 130 | 133 | > The personal token needs permission for public repositories and to read | |
| 131 | 134 | > profiles. It is used by `@node-core/utils` and by the landing job for | |
@@ -139,18 +142,20 @@ reporting a hard failure. | |||
| 139 | 142 | 3. Every positional argument starting at this one will be a pull request ID of | |
| 140 | 143 | a pull request with commit-queue set. | |
| 141 | 144 | ||
| 142 | - The script will iterate over the pull requests. GitHub CLI is used to check if | ||
| 143 | - the PR is waiting for CI to start (`request-ci` label) or still has pending | ||
| 144 | - GitHub checks. The PR is skipped if CI is pending. No other CI validation is | ||
| 145 | - done here since `git node land` will fail if the last CI failed. | ||
| 146 | - | ||
| 147 | - The script removes the `commit-queue` label, then runs `git node land`, | ||
| 148 | - forwarding stdout and stderr to a file. PRs that are only blocked on wait time | ||
| 149 | - should have already been filtered by the metadata check. If a hard readiness | ||
| 150 | - failure appears between the metadata filter and `git node land`, the landing | ||
| 151 | - job adds a `commit-queue-failed` label to the PR, leaves a comment with the | ||
| 152 | - output of `git node land`, and then aborts the landing session. If the abort | ||
| 153 | - fails, the queue stops instead of continuing in an unknown state. | ||
| 145 | + The script iterates over the pull requests. For each PR, it uses GitHub CLI to | ||
| 146 | + fetch the labels and select the multiple-commit policy, then runs | ||
| 147 | + `git node land`, forwarding stdout and stderr to a file. It does not perform a | ||
| 148 | + separate CI preflight; `git node land` performs the current readiness and CI | ||
| 149 | + validation. | ||
| 150 | + | ||
| 151 | + The script keeps the `commit-queue` label in place while `git node land` is | ||
| 152 | + running. PRs that are only blocked on wait time should have already been | ||
| 153 | + filtered by the metadata check. A hard or mixed readiness failure is passed | ||
| 154 | + through so `git node land` can produce the failure output. If the landing | ||
| 155 | + attempt fails for that or any other reason, the job replaces the | ||
| 156 | + `commit-queue` label with `commit-queue-failed`, leaves a comment with the | ||
| 157 | + output, and then aborts the landing session. If the abort fails, the queue | ||
| 158 | + stops instead of continuing in an unknown state. | ||
| 154 | 159 | ||
| 155 | 160 | Fast-tracked PRs use the metadata check before checkout and the landing script. | |
| 156 | 161 | If the fast-track request has not yet received enough collaborator thumbs-up, | |
@@ -164,8 +169,8 @@ If no errors happen during `git node land`, the script either pushes the direct | |||
| 164 | 169 | rebase landing to `main` or uses GitHub's squash merge API for single-commit and | |
| 165 | 170 | fixup landings. It then leaves a `Landed in ...` comment in the PR. GitHub | |
| 166 | 171 | closes PRs merged through the merge API automatically; for direct pushes, the | |
| 167 | - script closes the PR. Iteration continues until all PRs have done the steps | ||
| 168 | - above. | ||
| 172 | + script closes the PR. The script then removes the `commit-queue` label. | ||
| 173 | + Iteration continues until all PRs have done the steps above. | ||
| 169 | 174 | ||
| 170 | 175 | ## Reverting broken commits | |
| 171 | 176 | ||
| Back | FazBrowse Home | New Git URL |
0 commit comments