diff --git a/docs/CLI.md b/docs/CLI.md index 9375ba608fe..9466a604862 100644 --- a/docs/CLI.md +++ b/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. diff --git a/docs/Project-Configuration/Commit-Queue.md b/docs/Project-Configuration/Commit-Queue.md deleted file mode 100644 index f96ec0cdf17..00000000000 --- a/docs/Project-Configuration/Commit-Queue.md +++ /dev/null @@ -1,202 +0,0 @@ -# Commit Queue - -Evergreen's commit queue merges changes after the code has passed a set of tests. - -Evergreen supports GitHub's [merge queue](Merge-Queue), and intends to deprecate the commit -queue feature in favor of GitHub's merge queue. - -## Rationale -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. -* Every commit on the mainline branch is potentially releasable/deployable. - -## Workflow -The following is what logically happens, though Evergreen will parallelize tests for speed. -1. Changes are ready to be introduced to the repo. - -![repo_tree.png](../images/repo_tree.png) - -2. The changes are added to the end of the commit queue. - -![queue.png](../images/queue.png) - -3. When the changes come to the front of the queue, a set of tests are run on the changes. - -![merge_test.png](../images/merge_test.png) - -4. If the tests pass, the merge commit is pushed to GitHub. - -## Modes of Operation -Changes can be added to the commit queue from pull requests, the CLI, or the UI. -### PR -For projects that use GitHub pull requests for code review, the commit queue integrates with the PR workflow. When the PR is approved and ready to be merged, changes are added to the queue through the PR and commit queue feedback is provided in status checks on the PR. -#### Trigger -Add a PR to the commit queue by adding a comment on the PR: `evergreen merge` - -![comment.png](../images/comment.png) - -If successful, the PR will be merged with the PR title as the commit title. Any text after a newline in the "evergreen merge" comment will be added as the commit message. - -#### Feedback -Evergreen sends a status to the PR when the changes are enqueued, when the merge test has begun, and when the merge test is complete. Once the merge test has begun, the status links to the version. Note that because the commit queue merge is itself a Github check, you should omit the "evergreen/commitqueue" check from branch protection settings, if you require that checks pass before a PR can merge. - -![github_status.png](../images/github_status.png) -![github_status_fail.png](../images/github_status_fail.png) - -#### Set-Module -NOTE: this feature isn't currently working as expected. Fix is being tracked in [EVG-18256](https://jira.mongodb.org/browse/EVG-18256). -Add other PRs for repos defined as modules in the project's configuration file with the `--module MODULE:PR` option to the `evergreen merge` comment, where MODULE is the name of a module defined in the evergreen.yml project configuration file and PR is the PR number in the module's repo. When the test passes all the PRs will be merged. The option can be repeated for multiple modules. For instance: - -![set-module_comment.png](../images/set-module_comment.png) - -The module can only be set when initially adding the main PR to the commit queue since the test is immediately finalized. - -### CLI -For projects using other code review tools, changes can be uploaded to Evergreen using the `evergreen commit-queue` subcommands in the Evergreen CLI. -#### Trigger -`evergreen commit-queue merge --project ` - -Enqueue the branch checked out in Git on the project's commit queue to be merged into the project's tracked branch. - -##### Options -* `--pause` - -Upload the changes, but don't begin to test the changes. Used in conjunction with `evergreen commit-queue set-module` when the changes include corresponding changes to a module. - -* `--resume [ID]` - -Enqueue changes previously uploaded and paused. [ID] is the patch ID printed to the console when uploading the paused (unfinalized) patch. - -* `--commits [value], -c [value]` - -Pass in either a single commit hash, or a range `..` where `` is excluded from the range, and hash1 is an ancestor of hash2. - -* `--force` - -This flag forces the patch to the front of the queue. Use this sparingly and only for urgent scenarios, such as an urgent revert. -When trying to use this flag with a paused patch, use this flag along with the `--resume` flag and not the `--pause` flag. - -#### Feedback -The merge is performed by a "Commit Queue Merge" task added to the patch when the changes reach the head of the queue. - -![merge_task.png](../images/merge_task.png) - -#### Set-Module -`evergreen commit-queue set-module --patch --module ` - -Add changes to a project module. - -##### Options -* `--patch [ID], --id [ID], -i [ID]` - -Add to patch ID created with `evergreen commit-queue merge --pause` - -* `--module [module], -m [module]` - -Module name as defined in the project configuration file. - -##### CLI Set-Module Workflow -1. Upload the main changes to Evergreen. Retain the patch ID printed to the console. - -`evergreen commit-queue merge --pause ...` - -2. For each module to be merged, add the module to the patch - -`evergreen commit-queue set-module --id ...` - -3. Enqueue the changes on the commit queue - -`evergreen commit-queue merge --resume ...` - -### UI - -You can enqueue a **successful** patch to the commit queue using the Add to Commit Queue button (assuming that you own the patch or are a project administrator). - -![add_to_queue.png](../images/add_to_queue.png) - -All commits in the patch will be squashed, unless the patch was created using `--preserve-commits`. In this case, the commits will be tested together but merged separately. The title of the testing patch will be "Commit Queue Merge: <- " and if merged successfully, each commit will be merged with the commit title ( in the testing patch). - -![enqueue_patch.png](../images/enqueue_patch.png) - -## Notifications -Adjust your notifications on commit queue milestones on the [Notifications page](https://evergreen.mongodb.com/notifications). - -![notifications.png](../images/notifications.png) - -Milestones include: -* Changes reached the head of the queue and merge test has begun. -* Merge test passed/failed - -## Configuration -Project admins configure the commit queue through the [Projects page](https://spruce.mongodb.com/projects) in the Evergreen UI. Some settings are only available on spruce, so using the legacy UI for project settings is not recommend. On a per project basis, admin can -* Enable and disabled the commit queue -* Add a message to the commit queue -* Choose the [GitHub merge method](https://help.github.com/en/articles/about-merge-methods-on-github) (squash, merge, or rebase) -* Chose if signed commits are required -* Chose how many approvals are required on pull requests before they can be enqueued -* Add/remove patch definitions for tests to be run against PRs (tags or variant and task regexes) - - -## Queue Monitoring -The commit queue for a specified project can be viewed in the [web UI](https://spruce.mongodb.com/commit-queue/mongodb-mongo-master) -Additionally, the Evergreen CLI exposes two subcommands under `evergreen commit-queue` to monitor the commit queue - -### List -`evergreen commit-queue list --project ` - -List the patches on the project's queue. - -#### Options -* `--project PROJECT, -p PROJECT` list the queue of PROJECT - -### Delete -`evergreen commit-queue delete --item ` - -Delete a patch from a queue. Must be the user who uploaded the patch or a project admin. -If the patch is already picked up by the commit queue it will not be allowed to merge. - -#### Options - -* `--item ITEM, -i ITEM` - -Specify the patch ID to delete or PR number (if applicable) to delete. - -## Backport -Trivial backports can be automated with the commit queue. Create a backport patch to test the changes on the target branch, choosing the tasks necessary to validate the changes on the target branch. When the backport patch passes the changes are automatically added to the target branch's commit queue. **The backport patch is not added to the commit queue until tasks chosen have passed.** - -![backport.png](../images/backport.png) - -### Creating a backport patch -`evergreen commit-queue backport` - -#### Options -* `--backport-project, -b` - -Select the project corresponding to the target branch to backport onto. - -* `--alias, -a`, `--variants, -v`, `--tasks, -t` - -Specify the tasks to run in the backport patch. - -* `--commit-sha, -s`, `--existing-patch, -e` (mutually exclusive) - -Specify changes to backport. `--commit-sha` specifies a single commit to cherry-pick on top of the target project's tracked branch (this is from the same repository as the project). `--existing-patch` is the id of an existing commit queue patch in another project to pull changes from. - -## FAQ -> The merge test for a PR failed. How do I resubmit? - -Fix the PR and type another triggering comment. Do not restart the failing task. - -> The commit queue hasn't picked up my changes for a while. - -Check your position in the queue with the CLI. Evergreen checks the head of each queue about once a minute. - -> My project's branch is protected and only signed commits can be merged. Can I use the commit queue? - -Yes, but only if you add to the commit queue from pull requests. - -> What will the commit message be? - -For PRs, the commit message will be any text you type after the "evergreen merge" comment, separated by a newline. The commit title will always be the same as the PR title. - -If submitted by the CLI, the commits are recreated from the commits in your local repo and will retain their messages. diff --git a/docs/Project-Configuration/Evergreen-Data-for-Analytics.md b/docs/Project-Configuration/Evergreen-Data-for-Analytics.md index 7386ec576dd..65a5a180e74 100644 --- a/docs/Project-Configuration/Evergreen-Data-for-Analytics.md +++ b/docs/Project-Configuration/Evergreen-Data-for-Analytics.md @@ -27,7 +27,7 @@ Daily aggregated statistics for task executions run in Evergreen. Tasks are aggr | project\_id | VARCHAR | Unique project identifier. | variant | VARCHAR | Name of the build variant on which the tasks ran. | task\_name | VARCHAR | Display name of the tasks. -| request\_type | VARCHAR | Name of the trigger that requested the task executions. Will always be one of: `patch_request`, `github_pull_request`, `gitter_request` (mainline), `trigger_request`, `github_merge_request` (GitHub merge queue), `merge_test` (Evergreen commit queue), or `ad_hoc` (periodic build). +| request\_type | VARCHAR | Name of the trigger that requested the task executions. Will always be one of: `patch_request`, `github_pull_request`, `gitter_request` (mainline), `trigger_request`, `github_merge_request` (GitHub merge queue), `merge_test` (Evergreen commit queue, deprecated), or `ad_hoc` (periodic build). | finish\_date | VARCHAR | Date, in ISO format `YYYY-MM-DD`, on which the tasks ran. | num\_success | BIGINT | Number of successful task executions in the group. | num\_failed | BIGINT | Number of failed task executions in the group. @@ -52,7 +52,7 @@ Daily aggregated statistics for test executions run in Evergreen. Test stats are | variant | VARCHAR | Name of the build variant on which the tests ran. | task\_name | VARCHAR | Name of the task that the test ran under. This is the display task name for tasks that are part of a display task. | test\_name | VARCHAR | Display name of the tests. -| request\_type | VARCHAR | Name of the trigger that requested the task execution. Will always be one of: `patch_request`, `github_pull_request`, `gitter_request` (mainline), `trigger_request`, `github_merge_request` (GitHub merge queue), `merge_test` (Evergreen commit queue), or `ad_hoc` (periodic build). +| request\_type | VARCHAR | Name of the trigger that requested the task execution. Will always be one of: `patch_request`, `github_pull_request`, `gitter_request` (mainline), `trigger_request`, `github_merge_request` (GitHub merge queue), `merge_test` (Evergreen commit queue, deprecated), or `ad_hoc` (periodic build). | num\_pass | BIGINT | Number of passing tests. | num\_fail | BIGINT | Number of failing tests. | total\_pass\_duration\_ns | DOUBLE | Total duration, in nanoseconds, of passing tests. @@ -76,7 +76,7 @@ Finished Evergreen tasks, partitioned by the project and date (in ISO format). F | build\_id | VARCHAR | ID of the build containing the task. | order | BIGINT | Order number of the task's version. For patches this is the user's current patch submission count. For mainline versions this is the number of versions for that repository so far. | revision | VARCHAR | Git commit SHA. -| requester | VARCHAR | Name of the trigger that requested the task execution. Will always be one of: `patch_request`, `github_pull_request`, `gitter_request` (mainline), `trigger_request`, `github_merge_request` (GitHub merge queue), `merge_test` (Evergreen commit queue), or `ad_hoc` (periodic build). +| requester | VARCHAR | Name of the trigger that requested the task execution. Will always be one of: `patch_request`, `github_pull_request`, `gitter_request` (mainline), `trigger_request`, `github_merge_request` (GitHub merge queue), `merge_test` (Evergreen commit queue, deprecated), or `ad_hoc` (periodic build). | tags | ARRAY(VARCHAR) | Array of task tags from project configuration. | priority | BIGINT | Scheduling priority of the task. | task\_group | VARCHAR | Name of the task group that contains this task. @@ -172,7 +172,7 @@ Note that this is an estimated cost based solely on compute (`BoxUsage`) usage p | display\_name | VARCHAR | Display name of the task, will be the parent task's display name if part of a display task. | build\_variant | VARCHAR | Name of the task's build variant. | build\_variant\_display\_name | VARCHAR | Display name of the task's build variant. -| requester | VARCHAR | Name of the trigger that requested the task execution. Will always be one of: `patch_request`, `github_pull_request`, `gitter_request` (mainline), `trigger_request`, `github_merge_request` (GitHub merge queue), `merge_test` (Evergreen commit queue), or `ad_hoc` (periodic build). +| requester | VARCHAR | Name of the trigger that requested the task execution. Will always be one of: `patch_request`, `github_pull_request`, `gitter_request` (mainline), `trigger_request`, `github_merge_request` (GitHub merge queue), `merge_test` (Evergreen commit queue, deprecated), or `ad_hoc` (periodic build). | activated\_by | VARCHAR | User or service that activated this task. | tags | ARRAY(VARCHAR) | Array of task tags from project configuration. | host\_id | VARCHAR | ID of the host that ran this task. diff --git a/docs/Project-Configuration/Github-Integrations.md b/docs/Project-Configuration/Github-Integrations.md index 08001296823..eeb8a64735e 100644 --- a/docs/Project-Configuration/Github-Integrations.md +++ b/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 - -``` +## 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 diff --git a/docs/Project-Configuration/Merge-Queue.md b/docs/Project-Configuration/Merge-Queue.md index ad638cdc426..0b2d9a210fe 100644 --- a/docs/Project-Configuration/Merge-Queue.md +++ b/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. diff --git a/docs/Project-Configuration/Notifications.md b/docs/Project-Configuration/Notifications.md index 738e23bceac..6c470778dc6 100644 --- a/docs/Project-Configuration/Notifications.md +++ b/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. diff --git a/docs/Project-Configuration/Parameterized-Builds.md b/docs/Project-Configuration/Parameterized-Builds.md index 83a6db8603a..03c6034051a 100644 --- a/docs/Project-Configuration/Parameterized-Builds.md +++ b/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 diff --git a/docs/Project-Configuration/Project-Commands.md b/docs/Project-Configuration/Project-Commands.md index 6e7a5d685a0..af7682511cb 100644 --- a/docs/Project-Configuration/Project-Commands.md +++ b/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 `` 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 `` 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 diff --git a/docs/Project-Configuration/Project-Configuration-Files.md b/docs/Project-Configuration/Project-Configuration-Files.md index 151cb245258..163b8d7a854 100644 --- a/docs/Project-Configuration/Project-Configuration-Files.md +++ b/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. diff --git a/docs/Project-Configuration/Project-and-Distro-Settings.md b/docs/Project-Configuration/Project-and-Distro-Settings.md index cf528b801e3..64f7b817534 100644 --- a/docs/Project-Configuration/Project-and-Distro-Settings.md +++ b/docs/Project-Configuration/Project-and-Distro-Settings.md @@ -134,7 +134,7 @@ Options: ### Aliases -Aliases can be used for patch testing, commit queue testing, GitHub PRs, +Aliases can be used for patch testing, merge queue testing, GitHub PRs, GitHub checks, git tag triggers, project triggers, and patch triggers. For most aliases, you must define a variant regex or tags, and a task @@ -478,10 +478,10 @@ performance of tasks and tests. Project admins can set up notifications for when some events happen within the project. Admins can set up events when: -- Any version/build/task finishes/fails - these can be filtered by build initiator (commit, patch, PR, commit queue, +- Any version/build/task finishes/fails - these can be filtered by build initiator (commit, patch, PR, periodic build). - First failure occurs in a version, for each build or for each task name - these can be filtered by build initiator - (commit, patch, PR, commit queue, periodic build). + (commit, patch, PR, periodic build). - A previously-passing task fails - these can be filtered by failure type (any, test, system, setup). Furthermore, to reduce the amount of notifications received, the re-notification interval can be explicitly set. - A previously-passing test fails - these can be filtered by test name and failure type (any, test, system, setup). @@ -671,7 +671,9 @@ patch_aliases: - value: "defaultValue" ``` -### Commit Queue Aliases +### Merge Queue Aliases + +These apply to the [Github merge queue integration](../Merge-Queue). ``` yaml commit_queue_aliases: diff --git a/docs/Project-Configuration/Task-Priority.md b/docs/Project-Configuration/Task-Priority.md index 18108a464be..09b66b70440 100644 --- a/docs/Project-Configuration/Task-Priority.md +++ b/docs/Project-Configuration/Task-Priority.md @@ -11,7 +11,7 @@ However, note that these properties can overlap in complex ways. - Tasks that generate tasks are prioritized over tasks that do not. - Patches are prioritized over mainline commits. -- Commit queue patches are prioritized over patches and mainline. +- Merge queue patches are prioritized over patches and mainline. - Newer mainline builds are prioritized over older mainline builds. - Stepped back tasks are prioritized over non-stepped back tasks. - Tasks with more dependencies are prioritized over tasks with fewer dependencies.