Repositories which have protected branches with push restrictions have no ability to grant push rights to Integrations



I have an Integration that is designed to merge branches onto a repos master branch. It has full permissions for repository access. However, the Integration is not able to merge to master should it be protected using the ‘Restrict who can push to this branch’ access rights.

Trying with a test Integration with all access rights applied (include Repository Administration rights, not just code access rights) also fails to work. This leads me to suspect that the Github API doesn’t see an Integration that way, and expects a specific user to be pushing, which it can apply admin tests to.

However, as an Integration doesn’t have a Github ID per se, I cannot add it to the ‘Restrict who can push to this branch’ section. This means my Integration cannot merge to master; given it’s been designed to take away the ability from users who may not be carrying this out correctly, this is frustrating.

Is this an issue, or am I misunderstanding something?

Thanks in advance.


You could use a required Commit Status to do it.


Sorry, I don’t understand. How does a commit status help my Integration push when a restricted access list is in effect?

Could you go into detail as to how this would help?

Currently as I see it, either the restricted branch also needs to accept an Integration ID as a ‘user’ or some other permissions mechanism that override it needs to be available during Integration setup.


Instead of restricting the branch to a list of allowed users, you set the branch to require an integration-managed commit status. When your integration wants to push to your protected branch, it creates a passing commit status, then it pushes. Without that commit status, nobody else can push to the branch, and your integration is managing that commit status.

The only case where I think that can’t work is if you have more whitelisted users than just your integration.


Unfortunately, the case where it doesn’t work is the exact case that I have to deal with. Which is why I’d really like the ability to make the Integration a whitelisted user, or preferably have a set or permissions I can allow for the branch protection.

Thank you very much for the response, though, it’s appreciated.


This is affecting us as well.

We can and do have a required status check before a branch can be merged to master, however we want the integration to be the thing that actually performs this merge. Ideally merging is something people accept when they grant access to our repository - which I expected write access to repo to be. As a workaround we at least need some way to add our bot user to the allowed users so the merge functionality can continue to work.

Any updates on this would be appreciated.


@hedss, @notriddle, @jamielennox

Protected branches are looking for users or teams in your organization, not Integrations bots. I’ve added your feedback to the issue open requesting support for this and will let you know if/when we push a change to address this use case.


Yep, that’s what we figured.

From a user workflow perspective it would make sense to me that when I install an integration on my organization the integration user becomes a member of my organization. But I can also understand that maybe you don’t want to expose the concept of integration users to everyone.


I assumed this would be a permission on the ‘Repository contents’ section of Integrations, as it seems the logical place to implement this.


Is this still unsolved? My bot also fails to merge PRs when the repository is part of an Organization. Also, is there any way to detect via the GitHub API which repos my bot won’t be able to merge on? Permissions-wise we have read-write where necessary.


Upon more reflection, this looks like a clear bug that could be resolved without further configuration necessary by bot owners or organization administrators. An app that has already been granted write permission to code should clearly be allowed to push to the main branch by merging pull requests, regardless of what setting the repo has configured in “Restrict who can push to this branch”.

@sbarnekow is there any complication to this that I’m missing? Surprised this hasn’t been solved by now.


@rarkins it sounds like the reproduction conditions were a bit unclear. I think I have enough information to start chasing this one down. I’ll report back with my findings.


@kytrinyx do you have any update on this? I’m wondering if you plan to fix it without requiring configuration from organizations, or if you plan that organizations will need to add bot users (apps) to the list of allowed committers to protected branches?


@rarkins - this made it to the top of my list towards the end of Friday. I should have an update on it today.


Start to new user


I have a reproduction case, including a failing integration test. I’ll report back with more updates when I have them.


Giving bots merge access to protected branches could be a huge help for bots that maintain dependencies. Looking forward to this!


Quick update—I ran into a snag, and will need to work with one of my colleagues to untangle it. I’m going to need to put this on hold for a few days.


@kytrinyx have you determined yet whether the “fix” will be automatic - apps with read/write permissions will be able to merge again without further configuration - or will it be that you need to update the GitHub UI to allow apps to be added like users are to the list of allowed mergers?


You should not need any additional configuration for this to work, as far as I can tell, @rarkins