Branch protection settings don't work for wildcards

[iphydf]

Problem Description

Setting "name" to "*" in "branches:" doesn't do anything. Github supports wildcard matching of branches, and I'd like to be able to (I do, in my manual settings) apply branch protection rules to all branches in a repo.

What is actually happening

Nothing.

What is the expected behavior

A branch protection rule with "*" as name should appear.

Error output, if available

Question: where would I see the errors?

Context

Are you using the hosted instance of probot/settings or running your own?

Hosted.

[travi]

please be sure to look for similar issues when reporting problems. it sounds like this is a similar problem to what was reported in #136. are there any details in there that might help you get past this issue.

I havent had time to diagnose this issue very far, but if you dig deep enough to identify further details around the problem, i'm happy to guide further and would certainly be open to a PR if we can get far enough to decide what would help here. if you are able to confirm whether it works through the api outside of the settings app, such as with a curl request, that would be a huge help.

Question: where would I see the errors?

good question. since you mentioned using the hosted version, you wouldn't see them currently. this is why we ask whether you use the hosted version vs run your own. if you were running your own, you would have access to logs for your instance and could include details from there. one of the other high priority improvements planned is to include some of these details as part of check runs, so that you can see the reason for failures, even if you are using our hosted version.

[iphydf]

The solution is probably similar. TBH if I look at the github API docs, it doesn't look like they have support for this (the API call is something like /.../:branch/..., indicating that the branch must exist - the wildcard feature was added later, and it seems the API hasn't adapted yet), so there isn't much you can do right now other than contacting github about this feature request.

[travi]

there isn't much you can do right now other than contacting github about this feature request.

unfortunately, this is somewhat common with requests for additions to the settings app. i would encourage reaching out to github support with requesting the addition. if you get a useful response back, please include the details in appropriate issues here so we better understand the status.

[mkrakowitzer]

I don't believe this is an API issue, I tested this now and the API supports wildcards

mutation MyMutation {
  __typename
  createBranchProtectionRule(input: {repositoryId: "XXXXXXXXXXXXXXXXXX", pattern: "foobar*", restrictsPushes: false}) {
    clientMutationId
  }
}

This is the same for #136, also works fine with the graphql API.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[sagarvsh]

Hi All,

This is one of the features which we are badly waiting for. We use wildcards extensively to protect branches today, for example, any branch starting with release should be automatically protected. This is a critical feature in very rapid development repositories where more developers are actively working on. Adoption of settings bot in our organization has been very successful so far except for the most critical repositories, just because of this missing feature.

[travi]

this is functionality that i would very much like to see as well, but as a single maintainer, time has been tight for working on features like this. if this is important to you, i encourage you to work on adding the functionality and submit a pull-request. i'm happy to help you work through the details along the way if you decide to make such a contribution.

[dennisroche]

This is the same for #136, also works fine with the graphql API.

so, it looks like we need to use graphql endpoint. can the bot already do that?

edit: doesn't appear so. @travi would you support adding graphql to the bot? i can contribute the change if you can review...

https://docs.github.com/en/graphql/guides/migrating-from-rest-to-graphql