Mergify Configuration File

Everything you need to know about Mergify configuration file


The Mergify configuration file is an essential component of using our platform effectively. This document will provide a comprehensive overview of the file, including its name, format, and the data structure schema.

Mergify applies the following rule to find and use its configuration:

  • It reads the file named .mergify.yml, or, as a fallback, .mergify/config.yml or .github/mergify.yml from the repository root directory.

  • It reads the file from the default repository branch configured on GitHub — usually main.

  • It can extends the configuration by another configuration using the keyword extends — see “extending the configuration file”.

The configuration file uses the YAML format, which is both human-readable and machine-parsable. YAML is easy to read and edit, making it a popular choice for configuration files.

The file main type is a dictionary and each key of the dictionary configures a different aspect of Mergify:

The top-level key pull_request_rules allows to automate your workflow by writing rules that execute actions. It must be a list of dictionary with the following keys:

Key nameValue type
actions

Actions

The actions to perform when the rule matches.

conditions

List of conditions

The conditions that must be met for the rule to be evaluated.

descriptionstring or null

A description of the rule.

disabled

DisabledDict

or null

If the rule is disabled, the reason why it's disabled.

namestring

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.

Example:

pull_request_rules:
  - name: add label when author is jd
    description: jd needs his own label because reasons
    conditions:
      - author = jd
    actions:
      label:
        add:
          - jd

The top-level key merge_protections allows to protect your merge by adding a list of rules that must match before allowing the pull request to be merged.

Key nameValue type
descriptionstring or null

A description of the rule

if

List of conditions

The conditions to check before applying the rule

namestring

The name of the rule

success_conditions

List of conditions

The conditions to check to validate the rule

The top-level key queue_rules allows to define the rules that reign over your merge queues.

Key nameValue typeDefault
allow_checks_interruptionboolean or null
null
deprecated
allow_inplace_checksboolean
true

Allow to update or rebase the original pull request to check its mergeability when first in the queue and not part of a batch or speculative check.

allow_queue_branch_editboolean
false

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.

autosquashboolean
true

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.

batch_max_failure_resolution_attemptsinteger or null
null

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.

batch_max_wait_timeduration
30 seconds

The maximum amount of time to wait before creating a batch when the batch is not full.

batch_sizeinteger
1

The maximum number of pull requests per speculative check in the queue. Must be between 1 and 128.

branch_protection_injection_modequeue, merge or none
queue

Branch protections conditions injection mode to use.

  • queue will inject branch protections conditions as required conditions for queuing and merging pull requests.
  • merge will inject branch protections conditions as required conditions only for merging pull requests.
  • none will disable branch protections. This mode is supported only on queues using a merge_bot_account with admin rights.
checks_timeoutduration or null
null

The amount of time the merge queue waits for pending checks to return before dequeueing pull requests. This cannot be less than 60 seconds.

commit_message_templatetemplate or null
null

Template to use as the commit message when using the merge or squash merge method.

disallow_checks_interruption_from_queueslist of stringdeprecated
draft_bot_accountstring or null
null

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.

merge_bot_accounttemplate or null
null

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.

merge_conditions

List of conditions

The list of conditions to match to get the queued pull request merged. This automatically includes the queue_conditions. In case of speculative merge pull request, the merge conditions starting by check- are evaluated against the temporary pull request instead of the original one.

merge_methodmerge, rebase, squash or fast-forward or null
null

Merge method to use. If no value is set, Mergify uses the first authorized method available in the repository configuration. fast-forward is not supported on queues with max_parallel_checks > 1, batch_size > 1, or with allow_inplace_checks set to false.

namestring
priority_rules

PriorityRulesModel

deprecated

This attribute is deprecated in favor of priority_rules at the top level of the Mergify configuration file. The list of priority rules a pull request can match in order to be prioritized when added to a queue. The rule with the highest priority value wins.

queue_branch_merge_methodfast-forward or null
null

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.

queue_branch_prefixstring
mergify/merge-queue/
queue_conditions

List of conditions

The list of conditions that needs to match to queue the pull request.

speculative_checksinteger
1
deprecated

The maximum number of checks to run in parallel in the queue. Must be between 1 and 128.

update_bot_accounttemplate or null
null

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 picks randomly one of the organization users 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.

update_methodrebase or merge or null
null

Method to use to update the pull request with its base branch when the check is done in place. Possible values:

  • merge to merge the base branch into the pull request.
  • rebase to rebase the pull request against its base branch.

This option overrides the value defined in the queue rules section of the configuration. The default is rebase when the merge_method is fast-forward.

The top-level key priority rules allows to define the rules that will determine which priority a pull request has when entering your merge queue.

Key nameValue typeDefault
allow_checks_interruptionboolean
true

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.

conditions

List of conditions

The list of conditions that needs to match to assign priority to the pull request.

namestring

Name of the rule.

priorityhigh, medium or low or integer
medium

The priority of the pull request.

The top-level key partition_rules allows to split your repositories into independent partitions. This is especially useful when using a monorepo with the merge queue.

Key nameValue type
conditions

List of conditions

List of conditions to determine the partition(s) in which the pull request will be queued. If a pull request matches no partition, it is added to the fallback partition if defined. Otherwise it is added to every partition.

fallback_partitionboolean

Allow the partition to work as the fallback partition. There can be only one fallback partition.

namestring

Name of the partition

The defaults section provides a means to set configuration values that act as fallbacks for:

Instead of defining the same options repeatedly for different rules, you can specify them once in the defaults section. If a particular option is directly defined under pull_request_rules or queue_rules, it will take precedence; otherwise, the system resorts to the values defined in the defaults section.

defaults:
  actions:
    comment:
      bot_account: Autobot

  queue_rule:
    batch_size: 10

pull_request_rules:
  - name: comment with default
    conditions:
      - label = comment
    actions:
      comment:
        message: I 💙 Mergify

queue_rules:
  - name: default
    allow_inplace_checks: False

  - name: default with smaller batch
    allow_inplace_checks: False
    batch_size: 2

This configuration is equivalent to:

pull_request_rules:
  - name: comment with default
    conditions:
      - label = comment
    actions:
      comment:
        message: I 💙 Mergify
        bot_account: Autobot

queue_rules:
  - name: default
    allow_inplace_checks: False
    batch_size: 10

  - name: default with smaller batch
    allow_inplace_checks: False
    batch_size: 2

In the example, the bot_account value is taken from the defaults section, simplifying the pull_request_rules and ensuring consistent behavior across different rules. The same behavior applies for the batch_size option of the queue_rules, the default value of 10 gets applied to the queue rule default but not for the queue rule default with smaller batch, because it already has batch_size: 2.

You can store anything in the shared key. Its main purpose is to provide a place to put redundant YAML anchors. See Sharing.

Mergify offers a feature to extend your configuration file by incorporating settings from another repository, aiding in consistency and reducing duplication. This is achieved by using the extends keyword at the top of your configuration file and specifying the source repository. See Extending Configuration Files.

For those interested in a more detailed and machine-readable description of the Mergify configuration file format, a JSON Schema specification is available. This specification can help you understand the structure of the configuration file and can be used to generate client libraries, server stubs, or API documentation.

You can find the JSON Schema specification for the Mergify configuration here .

Validation and Troubleshooting

Section titled Validation and Troubleshooting

When working with Mergify’s configuration file, it’s essential to validate and troubleshoot any issues that may arise. Ensuring that your configuration file is error-free and well-structured can help prevent unexpected behavior and maintain a smooth workflow.

To validate your Mergify configuration file, you can use Mergify’s built-in validation tool. Whenever you push a change to the configuration file, Mergify will automatically validate the configuration and report any errors or warnings in the “Checks” tab of your pull request.

Mergify configuration check

If there are any issues with your configuration file, you will receive a detailed description of the problem and guidance on how to fix it. Be sure to address any errors or warnings to ensure optimal performance and avoid potential issues.

If you encounter issues or unexpected behavior with your Mergify configuration file, consider the following troubleshooting steps:

  1. Double-check the file name and location: ensure that your configuration file is correctly named (e.g., .mergify.yml) and is located in the right place. See Configuration File Name for details.

  2. Verify the YAML syntax: confirm that your configuration file follows the proper YAML syntax, including correct indentation, spacing, and structure.

  3. Review your rules and conditions: Make sure that your rules and conditions are correctly defined and accurately reflect your intended workflow.

  4. Check for conflicting rules: examine your rules for any conflicts or overlapping conditions that could cause unintended behavior.

  5. Consult Mergify’s documentation: refer to Mergify’s documentation for guidance on creating and managing your configuration file, as well as understanding the various features and options available to you.

By following these troubleshooting steps, you can effectively identify and resolve any issues with your Mergify configuration file, ensuring a smooth and efficient automation process for your repository.