When looking how the options are organized in the UI:

you see that options related to PRs are grouped slightly differently.

So we have the merge method (what we call enabled_merge_buttons) and then some other settings wrt auto merging, update and auto_merge.

Imho, we should have a pull_requests feature, that bundles all these options together, other than that the PR looks great.

Something that I would add as this easily leads to confusion is a link to the documentation of the auto merge feature: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request

One thing that is very important: auto merge does only make sense if you have a branch protection rule with at least 1 status check as the button will only be visible if the PR can not be merged right away.

The idea of this feature is that you normally have to wait some time till the checks complete and only then can you click the merge button. So you can already say: merge this PR if all checks pass.

Imho, we should have a pull_requests feature, that bundles all these options together, other than that the PR looks great.

What about backward compatibility? If I modify the schema to accept:

github:
  pull_requests:
    enabled_merge_buttons:
      squash: true

the old configuration will not work.

sorry I was not clear, I am not asking you to change that right away but I was wondering how to best organize these options. Adding the auto_merge to enabled_merge_buttons is also not fully correct and probably confusing.

So your are suggesting to have github.pull_requests.auto_merge?

tbh I am not sure right now. There exists github.del_branch_an_merge and the github.enabled_merge_buttons.
Now where to add allow_auto_merge?
Also we should support allow_branch_update which would be easy to add as well.

So when we would start from scratch I would add a github.pull_request container to add these things, but doing that would break a lot of .asf.yaml files.

@Humbedooh, any ideas?

what about adding a pull_requests feature that bundles the following things:

• del_branch_on_merge
• allow_update_branch
• allow_auto_merge

the del_branch_on_merge would need to be deprecated and old formats can still be read.

Edit: and at one point in the future when we feel motivated we can also migrate the existing enabled_merge_buttons to that pull_requests stuff.

Sounds good to me!

updated the PR with the outlined refactoring.

The legacy setting github.del_branch_on_merge is still supported. Once github.pull_requests is also used, an exception is raised when the legacy setting is still used and not migrated.

so imho, this looks clean, wdyt @Humbedooh

I removed the documentation of the initially proposed github.enabled_merge_buttons.auto_merge in f1611a6

LGTM, nice work.