Mergify Configuration
Mergify configuration file
| Type | object |
|---|---|
| File match |
.mergify.yml
**/.github/mergify.yml
**/.mergify/config.yml
|
| Schema URL | https://catalog.lintel.tools/schemas/github/mergify-configuration/latest.json |
| Source | https://raw.githubusercontent.com/Mergifyio/docs/main/public/mergify-configuration-schema.json |
Validate with Lintel
npx @lintel/lintel check
Properties
2 nested properties
18 nested properties
2 nested properties
Where scopes come from. files uses file-pattern rules (gha-mergify-ci-scopes must have been setup on your pull request); manual uses scopes sent via API or mergify scopes-send; None disables scoping.
Scope name automatically applied to merge queue PRs.
10 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
7 nested properties
The maximum number of speculative checks allowed to run at the same time. Setting this value to 1 disables speculative checks.
Defines the behavior of the merge queue when something is merged outside of the queue. "always": The queue is reset when an external merge is detected. All queued pull requests are re-evaluated to ensure correctness based on the new base branch state. "never": The queue remains unchanged. It does not reset or re-evaluate based on the external merge.
The label to add on pull requests when they are added to the merge queue.
The label to add on pull requests when they are removed from the merge queue.
Defines how the merge queue schedules pull requests.
serial: PRs are tested cumulatively.parallel: PRs whose scopes don't overlap are tested in parallel.
Allow PRs to merge even if their own speculative check fails, as long as a later downstream check including them passes and schedule conditions are valid.
Controls the level of status comments posted on pull requests in the queue.
all: Post comments for all queue events (entering queue, CI progress, outcomes).outcomes: Only post comments for final outcomes (merged or dequeued with failure reason).none: Do not post any comments for queue status.
2 nested properties
The merge protection reporting method
Whether to post merge protection status comments on pull requests
Definitions
Mergify can impersonate a GitHub user to copy a pull request. If no bot_account is set, Mergify copies the pull request itself.
The list of regexes to find branches the pull request should be copied to.
Whether to create the pull requests even if there are conflicts when cherry-picking the commits.
Users to assign the newly created pull request to. As the type is a data type template, you could use, e.g., {{author}} to assign the pull request to its original author.
The list of labels to add to the created pull requests.
The label to add to the created pull request if it has conflicts and ignore_conflicts is set to true.
The pull request's title.
The pull request's body.
Reporting modes for the action's result. Check will create a check on the pull request, and comment will post a comment on the pull request.
[
"check"
]
Style used by git when displaying merge conflicts
A Git branch name.
A string template using the Jinja2 syntax.
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
1 nested properties
The message to write as a comment.
Mergify can impersonate a GitHub user to comment a pull request. If no bot_account is set, Mergify will comment the pull request itself.
Indicates if the commit has been marked as verified by GitHub
Name of the author
Name of the committer
GitHub login of the author
Name of the author
Email address of the author
Mergify can impersonate a GitHub user to copy a pull request. If no bot_account is set, Mergify copies the pull request itself.
The list of regexes to find branches the pull request should be copied to.
Whether to create the pull requests even if there are conflicts when cherry-picking the commits.
Users to assign the newly created pull request to. As the type is a data type template, you could use, e.g., {{author}} to assign the pull request to its original author.
The list of labels to add to the created pull requests.
The label to add to the created pull request if it has conflicts and ignore_conflicts is set to true.
The pull request's title.
The pull request's body.
Reporting modes for the action's result. Check will create a check on the pull request, and comment will post a comment on the pull request.
[
"check"
]
Style used by git when displaying merge conflicts
18 nested properties
If set to true, the branch will be deleted even if another pull request depends on the head branch. GitHub will therefore close the dependent pull requests.
If set to true, all the approving reviews will be removed when the pull request is updated. If set to false, nothing will be done. If set to a list, each item should be the GitHub login of a user whose review will be removed. If set to from_requested_reviewers, the list of requested reviewers will be used to get whose review will be removed.
If set to true, all the reviews requesting changes will be removed when the pull request is updated. If set to false, nothing will be done. If set to a list, each item should be the GitHub login of a user whose review will be removed. If set to from_requested_reviewers, the list of requested reviewers will be used to get whose review will be removed.
Message to use when dismissing reviews.
If set to synchronize, the action will run only if the pull request commits changed. Otherwise, it will run each time the rule matches.
If the pull request should be a draft (true) or the other way around (false).
Glob patterns of files to include for this scope. Empty means 'include everything' before exclusions. Examples: ('src/**/*.py', 'Makefile')
Glob patterns of files to exclude from this scope. Evaluated after include and takes precedence. Examples: ('/tests/', '*.md')
GitHub Actions workflow action
1 nested properties
GitHub Actions workflow dispatch
The name of the .yaml GitHub Workflow file with its extension.
The reference to use when triggering the job. If none is passed, the default repository branch is used.
The inputs passed to your workflow execution if any. Values can be either a template, a number or a Boolean.
GitHub Actions workflow action
Add or remove labels on a pull request.
The list of labels to add.
The list of labels to remove.
Remove all labels from the pull request.
Toggle labels in the list based on the conditions. If all the conditions are a success, all the labels in the list will be added, otherwise, they will all be removed.
Merge method to use. If no value is set, Mergify uses the first authorized method available in the repository configuration.
Mergify can impersonate a GitHub user to merge pull requests. If no merge_bot_account is set, Mergify merges the pull request itself. The user account must have already been logged in Mergify dashboard once and have write or maintain permission.
Template to use as the commit message when using the merge or squash merge method.
The name of the rule
A description of the rule
The merge protection reporting method
Whether to post merge protection status comments on pull requests
The maximum number of speculative checks allowed to run at the same time. Setting this value to 1 disables speculative checks.
Defines the behavior of the merge queue when something is merged outside of the queue. "always": The queue is reset when an external merge is detected. All queued pull requests are re-evaluated to ensure correctness based on the new base branch state. "never": The queue remains unchanged. It does not reset or re-evaluate based on the external merge.
The label to add on pull requests when they are added to the merge queue.
The label to add on pull requests when they are removed from the merge queue.
Defines how the merge queue schedules pull requests.
serial: PRs are tested cumulatively.parallel: PRs whose scopes don't overlap are tested in parallel.
Allow PRs to merge even if their own speculative check fails, as long as a later downstream check including them passes and schedule conditions are valid.
Controls the level of status comments posted on pull requests in the queue.
all: Post comments for all queue events (entering queue, CI progress, outcomes).outcomes: Only post comments for final outcomes (merged or dequeued with failure reason).none: Do not post any comments for queue status.
Name of the partition
Allow the partition to work as the fallback partition. There can be only one fallback partition.
The title of the check.
The summary of the check.
List of conditions to match to mark the pull request check as succeeded, otherwise, it will be marked as failing. If unset, the conditions from the rule that triggers this action are used.
List of conditions to match to mark the pull request check as neutral, otherwise, it will be marked as failing.
Name of the rule.
The priority of the pull request.
Allow interrupting the ongoing checks when the pull request entering the queue has a higher priority than the queued one(s). If set to false, a pull request with higher priority will be inserted just after the pull requests that have checks running.
Whether the pull request is in draft state.
Whether the pull request is merged.
Whether the pull request contains changes in the configuration file.
Whether the pull request is closed.
Whether the pull request is locked.
Whether the pull request commits history is linear (no merge commit).
Whether the pull request is conflicting with its base branch.
The review decision. This indicates if CODEOWNERS have reviewed the pull request when the Require Review from Code Owners branch protection rule is enabled.
The pull request number.
The position of the pull request in its queue if queued. The first pull request in the queue has position 0. The value is set to -1 if the pull request is not queued.
The GitHub user or team login of the author of the pull request.
The GitHub user that merged the pull request.
The merge commit SHA of the pull request returned by GitHub.
The milestone title associated to the pull request.
The name of the branch the pull request should be pulled into.
The name of the branch where the pull request changes are implemented.
The head branch repository full name (complete version with the organization name).
The title of the pull request.
The content of the pull request description without Markdown/HTML comments.
The content of the pull request description.
The current repository name (short version without the organization name).
The current repository full name (complete version with the organization name).
A dequeue code for when a pull request has been disembarked from the merge queue.
The name of the queue containing the pull request.
The list of GitHub user or team login that are assigned to the pull request. Team logins are prefixed with the @ character and must belong to the repository organization.
The list of labels of the pull request.
The list of GitHub user or team login that were requested to review the pull request. Team logins are prefixed with the @ character. This only matches reviewers with admin, write or maintain permission on the repository.
The list of GitHub user or team login that approved the pull request. Team logins are prefixed with the @ character and must belong to the repository organization. This only matches reviewers with admin, write or maintain permission on the repository.
The list of GitHub user login that have their review dismissed in the pull request.
The list of GitHub user or team login that have requested changes in a review for the pull request.
The list of GitHub user that have commented in a review for the pull request. This only matches reviewers with admin, write or maintain permission on the repository.
The list of checks that successfully passed for the pull request.
The list of checks that failed for the pull request. Checks that report being cancelled, timed out, and action required are also considered as failures.
The list of checks that are neutral for the pull request.
The list of checks that timed out for the pull request.
The list of checks that was skipped for the pull request.
The list of checks that are pending for the pull request.
The list of checks for that pull request.
The list of checks that are stale for the pull request.
The list of commit messages that are marked as unverified by GitHub.
The list of deployments that successfully passed for the pull request.
The list of deployments that failed for the pull request.
The list of ids associated to review threads that are marked as resolved by GitHub.
The list of ids associated to review threads that are NOT marked as resolved by GitHub.
The files that are modified, deleted or added by the pull request.
The files that are added by the pull request.
The files that are modified by the pull request.
The files that are removed by the pull request.
The lines that are added by the pull request. Only usable as #added-lines for the number of added lines.
The lines that are modified by the pull request. Only usable as #modified-lines for the number of modified lines.
The lines that are deleted by the pull request. Only usable as #deleted-lines for the number of deleted lines.
The list of co-authors on the pull request (excluding merge commits and bots).
The list of commits between the head of the base branch and the base of the pull request. This can only be used with the length operator as #commits-behind.
The list of dependencies to other pull request in the format owner/repo#prnumber.
The dependency-name value included in the Dependabot commit message.
The dependency-type value included in the Dependabot commit message.
The update-type value included in the Dependabot commit message.
The list of commits of the pull request. The index 0 is the first commit, while -1 is the last commit.
The current date and time.
The time the pull request was updated at.
The time the pull request was created at.
The time the pull request was closed at.
The time the pull request was merged at.
The time the pull request was queued at for merge.
The time the pull request mergeability checks have started at.
The current time will be compared against this schedule to validate this attribute.
The GitHub login of the command author.
The list of updates done on an opened pull request.
The name of the rule. This is used when reporting information about a rule. It's not possible to have two rules with the same name.
18 nested properties
A description of the rule.
If the rule is disabled, the reason why it's disabled.
The name of the queue rule where the pull request should be added. If no name is set, queue_conditions will be applied instead.
Branch protections conditions injection mode to use.
queuewill inject branch protections conditions as required conditions for queuing and merging pull requests.mergewill inject branch protections conditions as required conditions only for merging pull requests.nonewill disable branch protections. This mode is supported only on queues using amerge_bot_accountwith admin rights.
The maximum number of pull requests per speculative check in the queue. Must be between 1 and 128.
The maximum amount of time to wait for additional pull requests before processing a batch that hasn't reached batch_size. The timer starts when the first pull request enters the batch. If batch_size is reached before this time expires, the batch processes immediately. This does not enforce a minimum delay between batches.
Deprecated: this value is computed automatically. In-place checks are enabled only when:
max_parallel_checks == 1- every queue has
batch_size == 1 - every queue CI is single-step (no extra
merge_conditions; either empty or identical toqueue_conditions)
The amount of time the merge queue waits for pending checks to return before dequeueing pull requests. This cannot be less than 60 seconds.
Number of times Mergify will retry failed CI checks before removing the pull request from the queue. On each retry, the draft pull request is recreated to trigger a fresh CI run. This is useful for handling flaky CI. When set to a value greater than 0, in-place checks are disabled and a draft pull request is always created. Set to 0 (default) to disable retries.
Mergify can impersonate a GitHub user to create its draft pull requests. If no draft_bot_account is set, Mergify creates the draft pull request itself. The user account must have already been logged in Mergify dashboard once and have admin, write or maintain permission.
If set to fast-forward, Mergify will merge the draft pull request instead of merging the original pull request that has been checked. This only works when merge_method is set to merge.
Prefix for the merge queue branch name
When creating a branch for a queue, if the commits of this branch are edited by an entity external to Mergify, Mergify dequeues all pull requests embarked in the branch and report the issue as a failure. If set to true, Mergify will allow such modifications and trust the content of the branch. Make sure only Mergify and your external application are allowed to edit these branches.
The number of attempts to resolve a batch failure before dequeueing pull requests. By default, Mergify will attempt to resolve a batch failure by splitting the batch multiple times until it finds the root cause of the failure. You can stop this process earlier by limiting the number of resolution attempts. Setting this to 0 will dequeue all the pull requests from a batch when a batch fails.
Merge method to use. If no value is set, Mergify uses the first authorized method available in the repository configuration.
This option is relevant only if you do in place checks and if you use the rebase option of the update_method. It will automatically squash your commits beginning by squash!, fixup! or amend!, just like the option with the same name when doing a git rebase.
When set to true, automatically add a pull request to the queue when it matches the queue conditions. When false, the pull request must be manually queued.
Method to use to update the pull request with its base branch when the check is done in place. Possible values:
mergeto merge the base branch into the pull request.rebaseto rebase the pull request against its base branch.
When null, defaults to merge except if merge_method is fast-forward then it defaults to rebase.
Template to use as the commit message when using the merge or squash merge method.
Mergify can impersonate a GitHub user to merge pull requests. If no merge_bot_account is set, Mergify merges the pull request itself. The user account must have already been logged in Mergify dashboard once and have write or maintain permission.
For certain actions, such as rebasing branches, Mergify has to impersonate a GitHub user. You can specify the account to use with this option. If no update_bot_account is set, Mergify uses the pull request author instead. The user account must have already been logged in Mergify dashboard once. This option overrides the value defined in the queue rules section of the configuration.
Branch protections conditions injection mode to use.
queuewill inject branch protections conditions as required conditions for queuing and merging pull requests.mergewill inject branch protections conditions as required conditions only for merging pull requests.nonewill disable branch protections. This mode is supported only on queues using amerge_bot_accountwith admin rights.
The maximum number of pull requests per speculative check in the queue. Must be between 1 and 128.
The maximum amount of time to wait for additional pull requests before processing a batch that hasn't reached batch_size. The timer starts when the first pull request enters the batch. If batch_size is reached before this time expires, the batch processes immediately. This does not enforce a minimum delay between batches.
Deprecated: this value is computed automatically. In-place checks are enabled only when:
max_parallel_checks == 1- every queue has
batch_size == 1 - every queue CI is single-step (no extra
merge_conditions; either empty or identical toqueue_conditions)
The amount of time the merge queue waits for pending checks to return before dequeueing pull requests. This cannot be less than 60 seconds.
Number of times Mergify will retry failed CI checks before removing the pull request from the queue. On each retry, the draft pull request is recreated to trigger a fresh CI run. This is useful for handling flaky CI. When set to a value greater than 0, in-place checks are disabled and a draft pull request is always created. Set to 0 (default) to disable retries.
Mergify can impersonate a GitHub user to create its draft pull requests. If no draft_bot_account is set, Mergify creates the draft pull request itself. The user account must have already been logged in Mergify dashboard once and have admin, write or maintain permission.
If set to fast-forward, Mergify will merge the draft pull request instead of merging the original pull request that has been checked. This only works when merge_method is set to merge.
Prefix for the merge queue branch name
When creating a branch for a queue, if the commits of this branch are edited by an entity external to Mergify, Mergify dequeues all pull requests embarked in the branch and report the issue as a failure. If set to true, Mergify will allow such modifications and trust the content of the branch. Make sure only Mergify and your external application are allowed to edit these branches.
The number of attempts to resolve a batch failure before dequeueing pull requests. By default, Mergify will attempt to resolve a batch failure by splitting the batch multiple times until it finds the root cause of the failure. You can stop this process earlier by limiting the number of resolution attempts. Setting this to 0 will dequeue all the pull requests from a batch when a batch fails.
Merge method to use. If no value is set, Mergify uses the first authorized method available in the repository configuration.
This option is relevant only if you do in place checks and if you use the rebase option of the update_method. It will automatically squash your commits beginning by squash!, fixup! or amend!, just like the option with the same name when doing a git rebase.
When set to true, automatically add a pull request to the queue when it matches the queue conditions. When false, the pull request must be manually queued.
Method to use to update the pull request with its base branch when the check is done in place. Possible values:
mergeto merge the base branch into the pull request.rebaseto rebase the pull request against its base branch.
When null, defaults to merge except if merge_method is fast-forward then it defaults to rebase.
Template to use as the commit message when using the merge or squash merge method.
Mergify can impersonate a GitHub user to merge pull requests. If no merge_bot_account is set, Mergify merges the pull request itself. The user account must have already been logged in Mergify dashboard once and have write or maintain permission.
For certain actions, such as rebasing branches, Mergify has to impersonate a GitHub user. You can specify the account to use with this option. If no update_bot_account is set, Mergify uses the pull request author instead. The user account must have already been logged in Mergify dashboard once. This option overrides the value defined in the queue rules section of the configuration.
To rebase, Mergify needs to impersonate a GitHub user. You can specify the account to use with this option. If no bot_account is set, Mergify picks the pull request author. The user account must have already been logged in Mergify dashboard once.
Warning: Due to security on GitHub side, rebase cannot be performed on pull requests created by bot accounts without explicitly setting the bot_account impersonation option.
When set to true, commits starting with fixup!, squash! and amend! are squashed during the rebase.
Mergify can impersonate a GitHub user to request a review on a pull request. If no bot_account is set, Mergify will request the review itself.
Pick random users and teams from the provided lists. When random_count is specified, users and teams can be a dictionary where the key is the login and the value is the weight to use. Weight must be between 1 and 15 included.
The usernames to request reviews from.
The team names to request reviews from.
The team names to get the list of users to request reviews from.
The type of review to post
The message to post in the review
Mergify can impersonate a GitHub user to review a pull request. If no bot_account is set, Mergify will review the pull request itself.
Model defining a single rule condition 'leaf of a condition tree'
Where scopes come from. files uses file-pattern rules (gha-mergify-ci-scopes must have been setup on your pull request); manual uses scopes sent via API or mergify scopes-send; None disables scoping.
Scope name automatically applied to merge queue PRs.
Mapping of scope name to its file filters. A file belongs to a scope if it matches the scope's include patterns and not its exclude patterns.
Scopes are manually sent via API or mergify scopes-send
Mergify can impersonate a GitHub user to squash a pull request. If no bot_account is set, Mergify will squash the pull request itself
Defines what commit message to use for the squashed commit if no commit message is defined in the pull request body. Possible values are:
all-commitsto use the same format as GitHub squashed merge commit.first-committo use the message of the first commit of the pull request.title+bodymeans to use the title and body from the pull request itself as the commit message. The pull request number will be added to end of the title.
Mergify can impersonate a GitHub user to update a pull request. If no bot_account is set, Mergify will update the pull request itself.