diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 714d1312..dd769bfb 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -105,7 +105,6 @@ - [AWS regions](./infra/docs/aws-regions.md) - [Bastion server](./infra/docs/bastion.md) - [Bors](./infra/docs/bors.md) - - [Fixing bors queue](./infra/docs/bors/queue-resync.md) - [CDN](./infra/docs/cdn.md) - [Crater agents](./infra/docs/crater-agents.md) - [Dev Desktops](./infra/docs/dev-desktop.md) diff --git a/src/infra/docs/bors.md b/src/infra/docs/bors.md index 17757f02..4c62d8d5 100644 --- a/src/infra/docs/bors.md +++ b/src/infra/docs/bors.md @@ -1,5 +1,7 @@ # Bors + + The infrastructure team manages an instance of [Homu] called "Bors", to be used for `rust-lang/rust`. The instance is available at [bors.rust-lang.org], and is backed by the [@bors] GitHub account. @@ -7,16 +9,6 @@ at [bors.rust-lang.org], and is backed by the [@bors] GitHub account. The service is configured [with Terraform][tf], and it's automatically deployed from the [rust-lang/homu] repository onto our [ECS cluster][ecs]. -## Maintenance procedures - -### Fixing inconsistencies in the queue - -Homu is quite buggy, and it might happen that the queue doesn't reflect the -actual state in the repositories. - -See [Fixing inconsistencies in the bors queue](./bors/queue-resync.md) for -instructions on how to do this properly. - [@bors]: https://github.com/bors [Homu]: https://github.com/rust-lang/homu [bors.rust-lang.org]: https://bors.rust-lang.org diff --git a/src/infra/docs/bors/queue-resync.md b/src/infra/docs/bors/queue-resync.md deleted file mode 100644 index d238ef10..00000000 --- a/src/infra/docs/bors/queue-resync.md +++ /dev/null @@ -1,147 +0,0 @@ -# Fixing inconsistencies in the bors queue - -bors queue page: . - -
- -**WARNING**: You should only do this if you have bors `r+` permissions on the -rust-lang/rust repo. Please do not synchronize if you do not have `r+` permissions -even if you have write access to the repo, as you will be unable to perform the -required cleanup steps. - -This is a **destructive** operation. If someone syncs, they need to -baby-sit the queue for around 45 minutes: around 30 minutes to wait for PRs to -be recollected, and 15 minutes after that to kick out PRs that should not be in -the tree. - -**DO NOT CLICK THIS BUTTON IF YOU ARE NOT ABLE TO HANDLE THE CLEANUP.** - -
- -Sometimes you have to do a bors queue sync for various reasons. This is not -trivial and requires you to be very careful, as otherwise we may accidentally -merge PRs to the default branch (or even `beta`) that should not have been merged -otherwise. - -## Steps - -### Step 0: Announce your intention - -Let T-infra (and other reviewers) know that you plan to close the tree. Open a -new [T-infra zulip -thread](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra) to let -other contributors know about the bors queue resync. - -### Step 1: Close the tree - -Find a PR that's currently being tested (or any open PR in the queue really if -the queue is *really* messed up). - -Issue `@bors treeclosed=1000` along with some brief explanation for why you are -closing the tree so other reviewers (especially people doing rollups) have some -context. - -Example: - -```text -Closing the tree due to a resync. -cc . - -@bors treeclosed=1000 -``` - -### Step 2: Click "synchronize" button - -As a courtesy, you can record which PRs had try jobs starting on them. After a -sync, the distinction between regular jobs and try jobs will be lost, so you'll -have to kick out all "pending" PRs. - -Click the "synchronize" button in the [bors queue page][bors-queue]. Then, -immediately start performing the next step. - -### Step 3: Kick out all actively tested PRs - -Find *all* actively tested PRs. This includes both "auto" builds (or full CI) -which show up as "pending", or "try" builds which show up as "pending (try)" -(but sometimes bors forget the distinction and try jobs can show up as "pending" -too). - -On each "pending" or "pending (try)" PR, write: - -```text -@bors retry r- (sync) -``` - -to suspend the current job and take it out of the queue (bors can confuse try -jobs with full CI jobs). - -### Step 4: Wait - -Wait for around **30-45 minutes** to allow bors to recollect all the PRs. **Do -not** reopen the tree beforehand, as it will cause bors to have an inconsistent -view of the PRs, which will lead to unspecified behavior. - -### Step 5: Kick out ineligible PRs - -Check "approved" PRs in the queue. Some of them will actually not be eligible -for merge, due to reasons such as: - -- Merge conflicts -- Significant changes since last review -- Never has been approved - -But sometimes bors forget these distinction. You'll need to manually visit each -of the "approved" PRs and check their eligibility. - -For "approved" PRs that are not actually eligible, you should kick them out of -the queue via `@bors r-`. Prefer to be cautious if you are not sure, and -unapprove the PR in case of ambiguity. - -```text -@bors r- (sync) -``` - -### Step 6: Double-check approved PRs - -Do another review pass of "approved" PRs in the queue, to make sure all approved -PRs are actually eligible for merge. - -### Step 7: Re-open the tree on the same PR where you closed the tree - -Reopen the tree on the same PR that you issued the `treeclosed` command with - -```text -@bors treeclosed- -``` - -Closely monitor bors' behavior for around 5 minutes, to ensure that bors is -correctly testing a PR that's eligible for merge. Update the relevant T-infra -zulip thread as suitable. - -### Step 8: Re-queue try jobs - -In Step 2, if you had to kick out try jobs, you can requeue the try jobs on the -PRs that previously had try jobs started on them. - -Use the normal try-job command: - -```text -@bors try -``` - -and not `@bors retry`. - -### Step 9: Edit your `treeclose` commands to prevent bors from picking them up - -Edit the `@bors treeclosed=xxxx` command and `@bors treeclosed-` command like - -```text -~~@/bors treeclosed=xxxx~~ - -EDIT(ferris): edited to prevent bors from picking up command in a future sync -``` - -AFTER the tree has been reopened to prevent bors from picking them up in a -future sync. - -[bors-queue]: https://bors.rust-lang.org/queue/rust diff --git a/src/libs/maintaining-std.md b/src/libs/maintaining-std.md index 54f355f9..b90032c0 100644 --- a/src/libs/maintaining-std.md +++ b/src/libs/maintaining-std.md @@ -338,7 +338,7 @@ To try reduce noise in the docs from deprecated items, they should be moved to t [`rust-lang/rfcs`]: https://github.com/rust-lang/rfcs [`rust-lang/rust-forge`]: https://github.com/rust-lang/rust-forge [`rfcbot`]: https://github.com/rust-lang/rfcbot-rs -[`bors`]: https://github.com/rust-lang/homu +[`bors`]: https://github.com/rust-lang/bors [pr_assignment]: ../triagebot/pr-assignment.md [`crater`]: https://github.com/rust-lang/crater [`rust-timer`]: https://github.com/rust-lang-nursery/rustc-perf diff --git a/src/release/index.md b/src/release/index.md index a4ded603..511e20af 100644 --- a/src/release/index.md +++ b/src/release/index.md @@ -5,7 +5,7 @@ support. ### External Links -* The [Homu/Bors] page provides links to the pull request testing queues for the +* The [bors] page provides links to the pull request testing queues for the `rust-lang` GitHub organisation, as well as providing an overview of the bot's syntax you can use to interact with it. * [Rustup Component History] documents when a component was last available (if @@ -17,5 +17,5 @@ support. [Rustup Component History]: https://rust-lang.github.io/rustup-components-history/index.html [PR Tracking]: https://rust-lang-nursery.github.io/rustc-pr-tracking/ -[Homu/Bors]: https://bors.rust-lang.org/ +[bors]: https://bors.rust-lang.org/ [`rustup-toolchain-install-master`]: https://github.com/kennytm/rustup-toolchain-install-master diff --git a/src/release/rollups.md b/src/release/rollups.md index f0474f4b..4ab4a20f 100644 --- a/src/release/rollups.md +++ b/src/release/rollups.md @@ -15,14 +15,14 @@ command accepts four values `always`, `maybe`, `iffy`, and `never`. See [the Rollups section] of the review policies for guidance on what these different statuses mean. -You can see the list of rollup PRs on Rust's [Homu queue], they are +You can see the list of rollup PRs on Rust's [bors queue], they are listed at the bottom of the 'approved' queue with a priority of 'rollup' meaning they will not be merged by themselves until everything in front of them in the queue has been merged. ## Making a Rollup -1. Using the interface on [Homu queue], select pull requests and then +1. Using the interface on [bors queue], select pull requests and then use "rollup" button to make a rollup pull request. (The text about fairness can be ignored.) **Important note**: consider for addition PRs marked as @@ -85,5 +85,5 @@ or confirm your hypothesis. If a rollup continues to fail you can run the `@bors rollup=never` command to never rollup the PR in question. -[Homu queue]: https://bors.rust-lang.org/queue/rust +[bors queue]: https://bors.rust-lang.org/queue/rust [the Rollups section]: ../compiler/reviews.md#rollups diff --git a/src/release/triage-procedure.md b/src/release/triage-procedure.md index 0e1009b3..ada58bb4 100644 --- a/src/release/triage-procedure.md +++ b/src/release/triage-procedure.md @@ -50,7 +50,7 @@ not need a review yet.) [s-experimental]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3AS-experimental+sort%3Aupdated-asc [no-status-tags]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Aopen+-label%3AS-waiting-on-author+-label%3AS-waiting-on-review+-label%3AS-waiting-on-team+-label%3AS-waiting-on-bors+-label%3AS-waiting-on-crater+-label%3AS-waiting-on-bikeshed+-label%3AS-waiting-on-perf+-label%3AS-blocked+-label%3AS-inactive+-label%3AS-waiting-on-fcp+-label%3AS-waiting-on-ACP+-label%3AS-experimental [crater]: https://github.com/rust-lang-nursery/crater -[bors]: https://github.com/rust-lang/homu +[bors]: https://github.com/rust-lang/bors ### Procedure