Hey all, any idea what's the best way to enable a Github Application to approve PRs? Usecase: Python library versions are published in upstream repo Downstream repos trigger a GHA that add the new version and open a PR that needs to be approved (gets put in merge queue automatically) So I want to automate the approval of the PR (which is perfect as we're happy as long as automated tests are passing) I've learned through doing that a GHA (authenticating to Github with the GHA Token) in one run cannot approve a PR created by another GHA with the same auth paradigm I've also learned that while a Github Application can approve a PR (I impersonated the App for testing purposes), branch protection rules mark this approval as an "un-approved reviewer" In the repo I tested (downstream consumer of the libray) we don't actually have a

.github/CODEOWNERS

defined. So I suppose by default this is determined by the

Collaborators and teams

repository-level settings. I guess looking at your repos I see a number of commits are by https://github.com/actions-user?

I would take a step back (xyproblem).

We no longer use this technique because repo/org rule sets support bypass rules, which we use instead

Yeah, a little bit more exploration revealed that I can configure a bypass for the Github Application. So in theory I should be able to set something up where the Github Application has bypass on a rule that requires approved reviewers. Then once tests pass the PR should auto merge. Likely a devil or two in the details still but such is life

So what’s the end goal with automating approval?

Currently someone needs to go into Github and approve the PR opened by the Github Action (which updates the repo to have the new python library version). The PR is already set for automerge once opened by Github Actions, so really just trying to automate away that last click. As long as tests are passing we're happy to upgrade. This is IMO on the one hand an incremental improvement as there'll be less slack in CI cycles / one fewer thing for the developers to think about. But the developers also have created a distributed monolith of sorts where the python library has sqlalchemy models in it (as multiple library-consumer services use the database), and every once in awhile there'll be a race condition between when downstream services have the latest models and when the migrations are run. We're looking at implementing an api driven feature flag system to help out with this, but having the upgrades be 100% automated will also help