application-services/.mergify.yml

47 строки
2.0 KiB
YAML

pull_request_rules:
- name: remove outdated reviews for non-core authors
conditions:
- base=main
- author!=@mozilla/application-services
- author!=@mozilla/application-services-collaborators
actions:
dismiss_reviews:
message: The pull request has been modified, dismissing previous reviews.
label:
remove:
- checkin-needed
- name: automatic merge for main
conditions:
- "#approved-reviews-by>=1"
- base=main
- label=checkin-needed
# What we want to say here is "all checks passed", but that's not a concept
# that makes sense in GitHub:
#
# https://docs.mergify.io/conditions/#validating-all-status-checks
#
# But we don't want to just list out all the checks, because we have many of
# them and some of them are added dynamically and we might add or remove checks
# without updating the list here.
#
# So instead we insist that a small set of known checks has completed,
# and also that there are no other checks in unexpected states.
- "check-success=Decision Task"
- "check-success=run-tests"
- "check-success=check-formatting"
- "#check-success-or-neutral>=5" # we should always have at least this many checks
- "#check-pending=0"
- "#check-stale=0"
- "#check-failure=0"
actions:
# This merges by rebasing without strict merge, which means that mergify will *attempt*
# to rebase a matching PR directly on to the `main` branch, even if the PR is out of date.
# However, our GitHub branch protection rules require that PRs must be up-to-date before merging,
# and mergify respects these rules, so the expected behaviour here is that mergify will only
# merge when it can cleanly put the exact commits of the PR directly on top of `main`
# (and thus avoid having to re-write any commits or create merge commits of its own).
merge:
method: rebase
rebase_fallback: none
strict: false