Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

github:add mergify configuration #275

Merged
merged 1 commit into from
Feb 6, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
79 changes: 79 additions & 0 deletions .github/mergify.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
---
defaults:
actions:
queue:
name: default
method: rebase
update_method: rebase


# each test should be listed separately, do not use regular expressions:
# https://docs.mergify.io/conditions.html#validating-all-status-check
# TODO: Use mergify's recently added 'shared configuration support'
# to dedup some of the check-x=y repetition in the future.
queue_rules:
- name: default
conditions:
- check-success=check
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we put in an explicit merge call here. I don't see a merge call which is confusing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

- check-success=build
- check-success=podmanbuild
- check-success=dockerbuild
- check-success=test
- check-success=test-kubernetes
- check-success=centos-ci/sink-clustered/mini-k8s-1.25
- check-success=dpulls


pull_request_rules:
# Clearing approvals after content changes
- name: Remove outdated approvals
conditions:
- base=master
actions:
dismiss_reviews:
approved: true
changes_requested: false
# Perform automatic merge on conditions
- name: Automatic merge on approval
conditions:
- check-success=check
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this covered by the default queue?

From what I understand, a queue action needs to be included to include the default queue. (Unless the defaults above calls it for you - but I prefer an explicit call to avoid confusion)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this covered by the default queue?
I mean the CI checks with the above comment.

- check-success=build
- check-success=podmanbuild
- check-success=dockerbuild
- check-success=test
- check-success=test-kubernetes
- check-success=centos-ci/sink-clustered/mini-k8s-1.25
- check-success=dpulls
- "-draft"
# Contributors should set the 'do-not-merge' label if they don't want
# the PR to be (auto)merged for some reason.
- "label!=do-not-merge"
# A reviewer should set a label starting with 'review-in-progress' (and
# suffixed by their username) in order to indicate a detailed review has been
# started and not completed. This will hold the PR until the label has been
# removed.
- "-label~=^review-in-progress"
- "base=master"
# Even if there are 2 or more approvals we won't automerge if there are
# any changes requested.
- "#changes-requested-reviews-by=0"
- or:
# Any contributor's PR can be automerged with 2 (or more) reviews.
- "#approved-reviews-by>=2"
# A maintainer's contribution only needs 1 review BUT we give a grace
# period over just two weeks for a 2nd reviewer to hopefully appear.
- and:
- "updated-at<15 days ago"
- "author=@maintainers"
- "#approved-reviews-by>=1"
actions:
queue: {}
dismiss_reviews: {}
Comment on lines +69 to +71
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At first, I though we may need an explicit queue.method (something like this), but if I read the merigfy queue docs correctly, then rebase is done automatically. Am I correct?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think defaults section at the very beginning plays a role here in determining the queue method.

The defaults section is used to define default configuration valued for actions run by pull request
rules and by Commands. If the options are defined in  pull_request_rules they are used, otherwise,
the values set in defaults are used.

# Conflict resolution prompt
- name: Ask contributor to resolve a conflict
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this pull_request_rule be above the previous one? From what I understand, the rules are executed in the order that they are listed.

conditions:
- conflict
actions:
comment:
message: "This pull request now has conflicts with the target branch.
Please resolve these conflicts and force push the updated branch."