DEVPROD-5859 Remove commit queue docs

docs/CLI.md

@@ -74,7 +74,7 @@ After setting defaults, you can omit the flags and the default values will be us
 
 Defaults may be changed at any time by editing your `~/.evergreen.yml` file.
 
-Additionally, the default project for a directory is also tracked by the first successful patch or commit queue merge you perform in that directory. Symlinks are resolved to their absolute path. The defaults are maintained in the `~/.evergreen.yml` file, under the `projects_for_directory` key. The value for this key is a map, where the map keys are absolute paths, and the map values are project identifiers. The automatic defaulting can be disabled by setting disable_auto_defaulting to true.
+Additionally, the default project for a directory is also tracked by the first successful patch you perform in that directory. Symlinks are resolved to their absolute path. The defaults are maintained in the `~/.evergreen.yml` file, under the `projects_for_directory` key. The value for this key is a map, where the map keys are absolute paths, and the map values are project identifiers. The automatic defaulting can be disabled by setting disable_auto_defaulting to true.
 
 Prompts
 ---
@@ -376,9 +376,6 @@ evergreen last-green -p mci -v ubuntu
 
 ```
 
-#### Commit Queue
-The command `evergreen commit-queue` contains subcommands for interacting with the commit queue. See [Commit Queue](Project-Configuration/Commit-Queue).
-
 #### Buildlogger Fetch
 
 The command `evergreen buildlogger fetch` downloads logs from cedar buildlogger.

docs/Project-Configuration/Github-Integrations.md

@@ -8,7 +8,7 @@ Specific GitHub pull request behavior can trigger behavior in Evergreen.
 evergreen help
 ```
 
-We have documentation here but we also provide it on the PR itself. It will display commands that are available for your project, with some context about when to use them. If the commit queue is disabled but there is an available message, we will still display the message. If PR testing isn't enabled for the branch but [PR testing is set up for untracked branches](../Project-Configuration/Repo-Level-Settings#how-to-use-pr-testing-for-untracked-branches) then we will also still show the related GitHub Pull request commands (detailed below).
+We have documentation here but we also provide it on the PR itself. It will display commands that are available for your project, with some context about when to use them. If PR testing isn't enabled for the branch but [PR testing is set up for untracked branches](../Project-Configuration/Repo-Level-Settings#how-to-use-pr-testing-for-untracked-branches) then we will also still show the related GitHub Pull request commands (detailed below).
 
 ## GitHub Pull Request Testing
 
@@ -28,8 +28,6 @@ evergreen retry
 
 Sometimes Evergreen has trouble creating a PR patch, due to internal server errors or GitHub flakiness. Commenting `evergreen retry` will attempt to recreate this patch. This can also be used to submit a new patch.
 
-Note that this is specific to GitHub PR checks; it won't retry a commit queue patch. For that, re-type `evergreen merge` (detailed below).
-
 #### Set PR patches to reuse a patch definition
 
 ```
@@ -81,18 +79,9 @@ Sometimes Evergreen has trouble sending updated GitHub statuses, so the checks o
 
 GitHub only allows one set of statuses for every commit SHA. If you have a situation where you have two PRs where the HEAD commit is the same, Evergreen will only create a patch for the first one and will make a comment on the second one explaining why. In general, if your tasks do not require the context of the PR (most notably the branch name, which is known to be used in some s3.put tasks), then the status displayed for the PRs will be correct. If the tasks do require the context of the PR, you may comment 'evergreen retry' and force Evergreen to abort currently running patches in favor of a new one in the context of the PR you have commented on.
 
-## Commit Queue
-
-Evergreen's commit queue merges changes after the code has passed a set of tests. You can read more about this [here](Commit-Queue#commit-queue).
-
-#### Add a PR to the commit queue
-
-```
-evergreen merge
-<any text here will be added as the commit message>
-```
+## GitHub Merge Queue
 
-To add a PR to the commit queue, comment `evergreen merge`. Any text after the newline will be added as the commit message.
+See [GitHub Merge Queue](../Project-Configuration/Merge-Queue.md) for more information.
 
 ## Github Check Runs
 

docs/Project-Configuration/Merge-Queue.md

@@ -4,9 +4,6 @@
 ensures that all pull requests pass required tests, rebased on HEAD, and it
 batches pull requests to test them as a unit to increase throughput.
 
-This is an alternative to Evergreen's commit queue, which the Evergreen team
-has deprecated in favor of GitHub's merge queue.
-
 Gating every merge on a green build means every commit on the tracked branch had a green build. This way:
 
 * No one bases their work on broken code.
@@ -15,10 +12,8 @@ Gating every merge on a green build means every commit on the tracked branch had
 To turn it on, you must turn on Evergreen's merge queue integration, and then
 turn on the GitHub merge queue in GitHub.
 
-You cannot use Evergreen's commit queue if the GitHub merge queue is on.
-
-Note that unlike Evergreen's commit queue, GitHub's requires that you have write
-access to the repository to merge, like you would have to without the queue.
+GitHub's merge queue requires that you have write access to the repository to
+merge, like you would have to without the queue.
 
 ## Enable the merge queue
 
@@ -56,7 +51,7 @@ all variants.
 Concurrency is on by default for the GitHub merge queue. If there are multiple
 PRs in the queue, your PR might be tested with other commits. This means that
 the Evergreen versions on a project patches page might be testing your PR even
-if they have a different commit queue title. This title is the title of the
+if they have a different merge queue title. This title is the title of the
 HEAD PR of a merge group, but the merge group could contain multiple PRs. Note
 that GitHub merges all commits from each PR before adding that PR to a version,
 so a given version has as many commits in it as there are PRs in it.

docs/Project-Configuration/Notifications.md

@@ -25,9 +25,6 @@ For your spawn hosts, you will receive notifications when a host is started, sto
 ### Spawn Host Expiration
 Receive notifications that your spawn host is going to expire soon, so you can update expiration accordingly if you don't want to lose the host.
 
-### Commit Queue
-Receive notifications on the status of your commit queue items.
-
 ### Build Break Notifications
 Project Admins may enable this at the project level.
 

docs/Project-Configuration/Parameterized-Builds.md

@@ -36,7 +36,7 @@ parameters:
 
 Note that value and description are not required. If value is not provided, the default value is the empty string.
 
-If the project configuration is modified, patches will use this value unless overridden through a higher-priority method. For **Pull Requests** and the **Commit Queue**, no higher-priority method is available, so modified parameters will be used.
+If the project configuration is modified, patches will use this value unless overridden through a higher-priority method. For **Pull Requests**, no higher-priority method is available, so modified parameters will be used.
 
 #### Command Line Usage
 

docs/Project-Configuration/Project-Commands.md

@@ -341,7 +341,7 @@ Parameters:
 
 downstream_expansions.set is used by parent patches to pass key-value
 pairs to child patches. This command only has an effect in manual patches,
-GitHub merge queue/legacy commit queue, and PRs. For all other versions, 
+GitHub merge queue, and PRs. For all other versions,
 it will no-op. The command takes the key-value pairs written in
 the file and makes them available to the child patches. Note: these
 parameters will be public and viewable on the child patch's page.
@@ -585,10 +585,11 @@ The parameters for each module are:
 
 #### Module Hash Hierarchy
 The hash used for a module during cloning is determined by the following hierarchy:
-* For commit queue and GitHub merge queue patches, Evergreen always uses the module branch name, to ensure accurate testing.
-* For other patches, the initial default is to the githash in set-module, if specified.
-* For both commits and patches, the next default is to the `<module_name>` set in revisions for the command.
-* For commits, if this is not available, the next default is to ref, and then to branch. *Note that this
+
+- For GitHub merge queue patches, Evergreen always uses the module branch name, to ensure accurate testing.
+- For other patches, the initial default is to the githash in set-module, if specified.
+- For both commits and patches, the next default is to the `<module_name>` set in revisions for the command.
+- For commits, if this is not available, the next default is to ref, and then to branch. *Note that this
 doesn't work for patches -- hashes will need to be specified in the revisions section of the command.*
 
 ## gotest.parse_files

docs/Project-Configuration/Project-Configuration-Files.md

@@ -633,7 +633,6 @@ The valid requester values are:
 - `commit`: mainline commits.
 - `trigger`: downstream trigger versions.
 - `ad_hoc`: periodic build versions.
-- `commit_queue`: Evergreen's commit queue.
 - `github_merge_queue`: GitHub's merge queue.
 
 By default, if no `allowed_requesters` are explicitly specified, then a task can
@@ -784,22 +783,20 @@ Every task has some expansions available by default:
     number, which increments on each commit, and includes the patch
     author name in patches
 -   `${github_pr_number}` is the Github PR number associated with PR
-    patches and PR triggered commit queue items
+    patches and PR triggered merge queue items
 -   `${github_org}` is the GitHub organization for the repo in which
-    a PR or PR triggered commit queue item appears
+    a PR or PR triggered merge queue item appears
 -   `${github_repo}` is the GitHub repo in which a PR or PR triggered
-    commit queue item appears
+    merge queue item appears
 -   `${github_author}` is the GitHub username of the creator of a PR
-    or PR triggered commit queue item
+    or PR triggered merge queue item
 -   `${github_known_hosts}` is GitHub's SSH key fingerprint
 -   `${triggered_by_git_tag}` is the name of the tag that triggered this
     version, if applicable
--   `${is_commit_queue}` is the string "true" if this is a commit
+-   `${is_commit_queue}` is the string "true" if this is a merge
     queue task
--   `${commit_message}` is the commit message if this is a commit queue
-    task
 -   `${requester}` is what triggered the task: `patch`, `github_pr`,
-    `github_tag`, `commit`, `trigger`, `commit_queue`, or `ad_hoc`
+    `github_tag`, `commit`, `trigger`, `github_merge_queue`, or `ad_hoc`
 -   `${otel_collector_endpoint}` is the gRPC endpoint for Evergreen's
     OTel collector. Tasks can send traces to this endpoint.
 -   `${otel_trace_id}` is the OTel trace ID this task is running under.