This will preserve your
but it will not preserve your “master/staging branch” settings (if you changed it),
and it will not preserve your list of reviewers.
Sorry for the hassle. Read further for an explanation of why this is needed.
Edit 27 July 2017: Changed broken links, since the main page for GitHub Integrations moved from
Issue #64 was a longstanding, showstopper bug that caused pull requests to be left open after bors merged them, and associated issues left open even though the pull request was supposed to close them after being merged. This issue has been successfully diagnosed and fixed on GitHub’s end.
However, the fix that was deployed by GitHub only kicks in when an integration has write access to the issue tracker. Bors did not request this level of access, and it cannot just add that level of access to the existing integration, so I made a new one.
The integration permission system
One of GitHub’s biggest selling points for integrations, over machine users and oauth applications, is the relatively fine-grained permissions system.
Unlike OAuth applications, which either have full access to a repository or no access at all, an integration developer can choose from eleven (11) different, disjoint, parts of your repository that it can request read-only, read-write, or no access to. When a user enables bors, for example, it will present them with this screen:
Once a user adds the integration to their repository, that’s it. There is no way for an integration to request additional permissions. It certainly can’t add new permissions silently; that would defeat the purpose of having a permission system in the first place.
Though GitHub did not comment on why fixing #64 requires adding Read/Write access for Issues, I assume it’s because they don’t want Read/Write access for Code to be sufficient permission to close an Issue. Allowing a “Write to Code, Read-Only to Issues” integration to close an isssue by pushing a commit but not by just using the API would incentivise integration developers to hack around the permission system.
How to upgrade your deployment of bors-ng
It is not possible to add a new permission to an integration. It is also not supported to migrate a bors database to a different GitHub integration (it contains integration-specific IDs that GitHub generates). The only supported way to fix the permissions on a bors-ng instance is to shut it down and wipe the database, delete the old integration, create a new integration, change the config to match the new integration, and re-add all the repos.
Again, this will lose some (but not all) of the settings.