Auto-merge support with "restrict who can push to this branch"

[nesl247]

Currently auto-merge is not possible for any branch that has "restrict who can push to this branch" enabled in branch protections.

Unfortunately GitHub does not currently allow adding bots to the list.

Is there any way to communicate with GitHub, especially since Dependabot is a Marketplace app?

[greysteil]

There's an issue on the GitHub platform forum, which is their preferred way to receive app-related feedback. Adding your voice there might help:

https://platform.github.community/t/repositories-which-have-protected-branches-with-push-restrictions-have-no-ability-to-grant-push-rights-to-integrations/1376/48

[nesl247]

I've gone ahead and replied and asked for an update. Unfortunately GitHub is slow as can be to do the most basic of things.

[kimadactyl]

Plus one, is it possible for us to add dependabot-bot as a user on the protected branch? It would require the bot responding to "add to team" requests. That's how Rultor does it :)

[greysteil]

Good question. Sadly not at the moment - we'd need to build a bunch of automation around dependabot-bot to make that work. It doesn't sound too hard, though, and is definitely the best workaround I've heard so far. I'm a little underwater with other requests, but will try to come back to this - ping me if I don't (and if there's no progress from GitHub - we're still pushing them).

[cihati]

Any progress on this one @greysteil ?

[greysteil]

This one's still with GitHub support. I chased them about it last week and just got another "it's on our roadmap" email. I know they're very busy, but hope this will become a priority eventually. In the meantime, the best way to help is probably emailing support@github.com.

[simlu]

We'd be very interested in a proper solution as well... Basically we want human prs to be reviewed before merging into our dev branch. However dependabot prs should be ok to auto merge. We could solve this independently from dependabot, however ideally it's solved by dependabot (if possible).

@greysteil What would be a appropriate request for the email you provided? If you post a template here more people might be tempted to sent that.

[greysteil]

I'd go for something like this:

To support@github.com:

Hi team,

I've got a feature request: we use Dependabot to create pull requests on repo-name and would like it to be able to automatically merge the PRs it creates, whilst continuing to require pull request reviews for PRs created by humans.

Currently, it looks like that's not possible under the branch-protection rules, particularly as Dependabot acts as a GitHub app (its username is dependabot[bot]). Are there any plans to add support?

Many thanks,

your-name

[simlu]

@greysteil Thanks!

We've solved this now in circleci using gally (disclaimer I'm the author) and a separate "bot" github user. Not as clean as I'd like it to be (oh circle why do you make our life so hard), but works great.

Excerpt (job):

  gally-auto-merge:
    docker:
      - image: 'circleci/node:10'
    steps:
      - run:
          name: Set PR number because circle :(
          command: |
            echo 'export CIRCLE_PR_NUMBER="${CIRCLE_PR_NUMBER:-${CIRCLE_PULL_REQUEST##*/}}"' >> $BASH_ENV
            source $BASH_ENV
            echo $CIRCLE_PR_NUMBER
      - checkout
      - run: sudo npm i -g gally
      - run: ga approve $CIRCLE_PR_NUMBER --condition "base.ref=dev&state=open&user.login=dependabot[bot]"
      - run: ga merge $CIRCLE_PR_NUMBER --condition "base.ref=dev&state=open&user.login=dependabot[bot]"

If you don't need approval you can skip that step in the job. Note that this requires the $GH_TOKEN environment variable to be set and contain the api key for the bot user.

[jodastephen]

I've played with this bot, and with some hacking managed to get it to auto-approve dependabot PRs so they then can be merged.

@greysteil, Ideally, this would be a new config option in dependabot, but I'm not sure if it is as simple as that. You can't normally approve your own PR, but maybe you can through the API? Otherwise, how about a new bot - approvabot ?

[greysteil]

We can't approve our own PRs, but a GitHub action to automatically approve them ought to work. I think @hmarr had something basic thrown together.

[hmarr]

I've just fixed up the auto-approval action I threw together a while ago and made the repo open source.

If you have access to GitHub Actions (and are using a private repo, as I gather they're not yet enabled for open source repos), this should do the trick for you.

https://github.com/hmarr/actions/#auto-approve

[AzureMarker]

@hmarr That bot does not seem to solve the issue.

For clarification, this issue is about the "Restrict who can push to matching branches" option, which only allows the specified users or teams to push to the branch. What your Action solves for is when "Require pull request reviews before merging" is enabled, which is not the point of this issue.

[nicolasrouanne]

Any workaround without GitHub Actions (I'm not yet into the beta 😢)?

[greysteil]

We're working on a general fix for this in GitHub right now (i.e., allowing you to specify bots as actors that are allowed to push to protected branches).

[nicolasrouanne]

For those who don't have GitHub Actions yet the autoapproval bot is working great. You can self host it (source code) or add the GitHub app (that's what I did).

Here is my .github/autoapproval.yml settings file:

from_owner:
  - dependabot-preview[bot]
required_labels:
  - dependencies
apply_labels:
  - autoapproved

So basically:

• autoapproval approves dependabot PRs automatically
• dependabot auto-merges its PRs since they are approved
• me: ☕️

[AzureMarker]

@nicolasrouanne that kind of fix is unrelated to this issue, as I previously mentioned:

For clarification, this issue is about the "Restrict who can push to matching branches" option, which only allows the specified users or teams to push to the branch. What your Action solves for is when "Require pull request reviews before merging" is enabled, which is not the point of this issue.

#86 (comment)

[greysteil]

@Mcat12 we'll have a fix for that direct in GitHub (and usable for other apps, not just Dependabot) in the next few days. @feelepxyz is working on it right now 🙂

[AzureMarker]

@greysteil Can you update this issue when the feature has been released?

[greysteil]

For sure. The whole of GitHub is at a big offsite this week so it won't happen in the next 7 days, but the code is almost ready and should be deployed next week.

[karltaylor]

@greysteil enjoy your offsite

[StephanBijzitter]

Perhaps it should be an issue of its own, but for several of our repositories we do not trust our test coverage enough to go full automatic.

One of our repositories now uses autoapprove + dependabot and that's working nicely, but for two other repositories we'd prefer to manually approve pull requests from dependabot and have dependabot merge them as soon as all other status checks have come back positive. That way we don't have to wait for the build to complete.

I may have been rambling a bit, so maybe this could summarise the option I'd also like to see (next to the fully automatic solution):

• Dependabot creates PR
• Developer approves while build is in progress
• Build finishes
• Dependabot merges PR

And

• Dependabot creates PR
• Build finishes
• Developer approves
• Dependabot merges PR

Currently we get:

Dependabot tried to automerge this PR, but received the following error from GitHub:

At least 1 approving review is required by reviewers with write access.

As a result, we've disabled automerging on this repo (you can re-enable it in your Dependabot settings).

Which is preventing us from doing that while we're working on our test coverage

[greysteil]

It’s still happening, but it’s slow. Here’s how it works internally at GitHub: - Dependabot is a team here - Another team (ecosystem-apps) owns the experience and code here - We’ve chatted to them, got the work scopes, and started working on it with their blessing (they’ll be responsible for hitting merge) - As part of the work we’ve found a bunch of debt around permissions which we’re working to clear up, but it’s slow going for us because it’s not our area and the person who was working on it is on holiday - We’ll keep pushing and get this over the line (I’ll update here if we ever *don’t* have someone working on it!) Stay with us - we’re working on it but it’s hard!

…

On 1 Aug 2019, at 08:00, Alex Cazacu ***@***.***> wrote: Are there any updates on the incoming change? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[NargiT]

You could use policy-bot from palantir that replace and enhance the branch protection by adding a status check to the pull request. If you configure your repo with branch protection for status check. Then you should be able to merge even if it is a bot. https://github.com/palantir/policy-bot

[feelepxyz]

👋 We've just shipped the UI to allow installed GitHub Apps to push to protected branches, you can add installed apps from the repository settings for the protected branch:

Short video walkthrough: https://drive.google.com/open?id=1i15psbTl7LhSMhNCi9tom-OdgybM9slQ

If you've got required pull request reviews set Dependabot will still fail to merge the pull request until it's approved. You can get around this with a GitHub action to auto approve these pull requests: https://github.com/hmarr/auto-approve-action

We're still working on the corresponding APIs to query/update apps as allowed actors on protected branches (GraphQL v4 and Rest v3). Planning on publishing these by next week.

There's also a bug when using git auth (e.g. git push with credentials) preventing apps from pushing to protected branches even though it's been authorized. Should be fixed by next week.

🎉

[simlu]

@feelepxyz Can you please update this ticket when this is supported through the api? Cheers!

[feelepxyz]

@simlu the APIs are now live 🎉

Updated GraphQL API:

• https://developer.github.com/v4/object/pushallowance/
• https://developer.github.com/v4/changelog/2019-08-23-schema-changes/

Updated Rest API: https://developer.github.com/changes/2019-09-05-apps-protected-branches-api/

[localheinz]

Any news on this one?

[feelepxyz]

@localheinz this should be working now if you add Dependabot Preview to the list of actors with push access on the protected branch. What's not working?

[localheinz]

@feelepxyz

The actor Dependabot Preview (or any other Dependabot actor) does not show up:

What do I need to do to make this happen?

[philsturgeon]

I'm also not seeing the name show up.

[feelepxyz]

@philsturgeon @localheinz oh looks like this is broken. Will investigate!

[feelepxyz]

@localheinz @philsturgeon workong on a fix in github but going to take some time to get this out amidst the holidays. You can work around it by explicitly selecting the repos that Dependabot Preview has access to instad of All repositories on the installation.

[localheinz]

@feelepxyz

Can confirm that selecting repositories manually allows to select @dependabot-preview!

[localheinz]

@feelepxyz

Not sure if this is a different issue, but I still do not see Dependabot automatically merge pull requests.

Apps allowed to push to matching branches

@dependabot-preview is on the list of apps allowed to push to matching branches (in this case, master)

.dependabot/config.yml

.dependabot/config.yml hopefully has the appropriate configuration:

# https://dependabot.com/docs/config-file/

version: 1

update_configs:
  - automerged_updates:
      - match:
          dependency_type: "development"
    default_assignees:
      - "localheinz"
    default_labels:
      - "dependency"
    default_reviewers:
      - "localheinz"
    directory: "/"
    ignored_updates:
      - match:
          dependency_name: "composer-plugin-api"
      - match:
          dependency_name: "composer/composer"
    package_manager: "php:composer"
    update_schedule: "live"
    version_requirement_updates: "increase_versions"

CODEOWNERS

I also have CODEOWNERS configured on the organization level and enabled on the repository level.

Example

I would have expected ergebnis/composer-normalize#283 to be merged automatically.

However, this has not happened.

Modifications required?

Do I need to remove the default_reviewers configuration?

diff --git a/.dependabot/config.yml b/.dependabot/config.yml
index 26a20fe..0778a1b 100644
--- a/.dependabot/config.yml
+++ b/.dependabot/config.yml
@@ -10,8 +10,6 @@ update_configs:
       - "localheinz"
     default_labels:
       - "dependency"
-    default_reviewers:
-      - "localheinz"
     directory: "/"
     ignored_updates:
       - match:

Should I stop using CODEOWNERS or configure it differently to exclude composer.json and composer.lock?

[romrell4]

I'm still not seeing the option to add dependabot-preview (or any other dependabot users) to my list of people with push access. Is this bug not completely fixed? I am also unable to manually select all repositories (since we have thousands, and need our bot to automatically have access to new ones). Any updates on this bug?

[feelepxyz]

@romrell4 this should be fixed now. Was on hold over the break.

@localheinz yeah looks like the required reviewers settings are preventing the automerge: ergebnis/composer-normalize#283 (comment) there's an option to treat a PR approval as a request to merge in your dependabot dashboard settings:

[localheinz]

Thank you, @feelepxyz!

[chris48s]

Just to clarify my understanding on this issue, is this summary of the situation correct?

Dependabot can now be added with permissions to push to protected branches, but it can't approve its own PRs. In order to trigger the merge, you still need either a manual approval, or another bot/action (other than dependabot) to approve the PR, even if a PR matches rules in automerged_updates.

[feelepxyz]

Dependabot can now be added with permissions to push to protected branches, but it can't approve its own PRs. In order to trigger the merge, you still need either a manual approval, or another bot/action (other than dependabot) to approve the PR, even if a PR matches rules in automerged_updates.

Yep, that's correct! Here's an example GH Action to auto-approve: https://github.com/hmarr/auto-approve-action (going to lock this issue)