-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Add GitHub App service #12072
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add GitHub App service #12072
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds a GitHub App service to support synchronizing installations and remote repositories while maintaining backward compatibility with existing integrations. Key changes include:
- Adding GitHub App–specific models, service methods, and deletion logic.
- Introducing a new GitHub App webhook URL and client for integration.
- Updating service registries and test cases to account for GitHub App behavior.
Reviewed Changes
Copilot reviewed 16 out of 23 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
readthedocs/oauth/models.py | Added GitHubAppInstallation methods and constants support |
readthedocs/oauth/urls.py | Introduced a dedicated GitHub App webhook URL |
readthedocs/oauth/clients.py | Added a client for GitHub App integration |
readthedocs/oauth/querysets.py | Updated querysets to exclude GitHub App related objects |
readthedocs/settings/docker_compose.py | Added environment variables for GitHub App configuration |
readthedocs/oauth/services/init.py | Updated the service registry to include GitHubAppService |
readthedocs/settings/base.py | Added default settings for the GitHub App integration |
readthedocs/settings/test.py | Added test settings including a sample RSA private key for GitHub App |
readthedocs/oauth/services/base.py | Defined base methods for cloning token retrieval, updated with GitHub App behavior |
readthedocs/projects/models.py | Updated GitHub project checks to consider both GitHub services |
readthedocs/urls.py | Included OAuth URL patterns for handling GitHub App webhooks |
readthedocs/rtd_tests/tests/test_oauth_tasks.py | Extended tests to include GitHubAppService sync calls |
Files not reviewed (7)
- docs/dev/install.rst: Language not supported
- docs/dev/settings.rst: Language not supported
- requirements/deploy.txt: Language not supported
- requirements/docker.txt: Language not supported
- requirements/pip.in: Language not supported
- requirements/pip.txt: Language not supported
- requirements/testing.txt: Language not supported
Comments suppressed due to low confidence (1)
readthedocs/oauth/services/base.py:334
- Duplicate definitions of 'get_clone_token' exist in this class; merge the implementations to prevent unintended overriding and ensure a single consistent behavior.
def get_clone_token(self, project):
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks great -- it's a big change tho, and a little scary. Had a bunch of smaller comments, but I think it could also be useful to describe the architecture a bit more in our dev docs somewhere. It seems like there's a bunch of webhooks, and we're syncing data based on those, but it was hard for me to wrap my head around the whole flow of data and responsibility of each piece.
Hope this helps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it could also be useful to describe the architecture a bit more in our dev docs somewhere.
Hope this helps https://github.com/readthedocs/readthedocs.org/pull/12072/files#diff-0bbc5fbaa17dc973c571176f0ac6bdc3849be5fe9b81aeb4847318df613740c6
Yea, that's great.
This looks great to me. To confirm, when we merge this we mostly are still installing backend infrastructure, and there is still not a user-facing change with this? If so, I think I'm 👍 on merging it, but would also love for another set of eyes on it before we ship it.
yep, we can actually start testing it in our own repos by manually linking projects to a remote repository. |
Metadata (read only, so we read the repo collaborators), | ||
Pull requests (read and write, so we can post a comment on PRs in the future). | ||
- Organization permissions: Members (read only so we can read the organization members). | ||
- Account permissions: Email addresses (read only, so allauth can fetch all verified emails). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be preferred if these permissions are on an opt-in basis. Many projects may want to start small, and i've seen plenty of them that are skeptical about every little permission. So instead it could be like
The minimum permissions necessary for this app are
- Repository permissions:
Contents (read only, so we can clone the repo contents)
Additionally you may grand additional permissions depending on the features you wish to have
- Repository permissions:
Commit statuses (read and write, so we can create commit statuses)
It does require the app to read the granted permissions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, don't think GH allows for this, the permissions are defined by the app, installations can't choose a subset of permissions. What can happen is that the app requires more permissions and the user can accept or reject those new permissions, but all new installations will always require granting all permissions designated by the app.
And even if GH allows for this, not sure that we will support that case, as it requires considering more cases to support, and also support time, as some users don't know why a feature isn't working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pushing the review I was able to do today so @stsewd has some feedback from my side; but it's not finished yet. I will continue tomorrow with it.
# NOTE: do we need the email of the organization? | ||
remote_org.email = gh_org.email |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me 👍🏼 Nice work!
Summary of comments:
- there is a pattern that I don't like too much:
variable = self.install.property
raises an exception - there are some tests where we only check if a method was called, but we don't check changes in the db -- it seems we are missing easy checks we can perform there
}, | ||
} | ||
r = self.post_webhook("pull_request", payload) | ||
assert r.status_code == 200 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the goal of this webhook? Just communicate to GitHub that we handled it but we do nothing? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We handle the pull_request event, but with we don't do anything with the "edited" action.
dev docs are failing because intersphinx is using the data from the current latest version instead of this PR. |
This is the big one :D
/webhook/githubapp/
URL, we can change that if needed.Extracted from #11942