You can configure required checks in a few different ways. Use GitHub mergeability This is the default setting. When this configuration is enabled, Aviator will fetch the required checks from GitHub’s branch protection rules. These are also the default required checks for validating draft PRs in parallel mode. Copy

merge_rules:
  labels:
   trigger: "mergequeue"
  preconditions:
    use_github_mergeability: true

Custom required_checks You can alternatively specify a set of separate required checks. This may be useful if you want additional validation before merging your PR, or if you have different requirements for various base branches. The custom checks can be specified from the merge rules UI or from the config file. Specifying from the merge rules UI Aviator already pre-populates all the checks from your repository here and default selects the required GitHub checks. Customize required checks modal Specifying from config file While specifying in the config file, you should follow the naming convention as specified in your GitHub pull requests. Typically it is the full bolded name in the PR. Example: status checks from GitHub Pull Request So in this case, the check for the last CircleCI test will be

ci/circleci: pytest

, but for the case of GitHub actions, only the job name is used (after forward slash). So the above check names would be in-order: Using wildcards You can use wildcards (*) while specifying required CI checks. Example: With this wildcard, Aviator will validate all checks with names matching this expression. This validation requires at least one matching check to be present. Conditional checks You can set custom acceptable statuses in the required check to support additional check statuses other than the default success. In the below example, Aviator will only consider the check unit-test as passing if we receive a success status. But for the check named conditional_build , Aviator will also consider a skipped status as passing. You can see all possible

acceptable_statuses

in the reference doc . These map to the statuses defined by GitHub here . Optional checks There are scenarios where a check is only run in certain conditions. In such cases, you would want to validate the check when it runs, but also accept the state when the check is not run at all. For this particular scenario, you can define the acceptable_statuses as success and missing: Override checks (for parallel mode) You can customize the required checks for parallel mode using the Merge Rules UI or via the config file. You can read more here . Here’s an example to do this in the config file: Require all checks passing You can also configure Aviator to enforce all checks to pass. If true, any failing test will cause the PR to be dequeued. This may work well if your repo has conditional checks. Requires at least one check to be present. You can set this both for the original PR and the draft PR. Previous How to Configure Base Branches Next How to Set Up Fast-Forwarding Last updated 8 months ago Was this helpful?