Sync versions when creating/deleting versions #4876
Conversation
| 'build_triggered': False, | ||
| 'project': project.slug, | ||
| 'versions': [version], | ||
| } |
There was a problem hiding this comment.
Still not sure about what to return, I'm returning the version that was used to do the clone, I guess this isn't so important, I mean, no one uses this, it's just sent to the integration (GitHub)
Codecov Report
@@ Coverage Diff @@
## master #4876 +/- ##
=========================================
+ Coverage 76.65% 76.7% +0.05%
=========================================
Files 158 158
Lines 10057 10098 +41
Branches 1269 1274 +5
=========================================
+ Hits 7709 7746 +37
- Misses 2007 2010 +3
- Partials 341 342 +1
|
|
I'd like to have an early review here (GitHub is done), I think we could just sync the versions without cloning the repo (not sure yet, I'll investigate tomorrow) |
|
I didn't found any cons in using the response from the provider's API to sync the versions, I think I'll go for that method. I'll leave the previous commits if we decide to go for cloning the repo. |
|
Actually, GitHub doesn't return the commit sha :/, and that's something we kind of rely on tags. So, back to do the cloning. We can change the way tags are represented I think, something for later anyway. |
|
Gitlab is done, but I'll need to test it locally. |
|
Just tested gitlab, it's working :D |
|
Bitbucket is tested too, but I had to setup the webhook manually because I wasn't able to do the auth integration. I think this is ready for review. |
There was a problem hiding this comment.
I like these changes. I think it's close to be merged.
The code takes some decisions depending on the VCS service we receive the webhook. Reading the code without the context on how each service works is hard to understand (I need to google by myself the docs for each service and compare it with your code). Because of this, I'd like to see more comments on each of these decisions with links to the documentation.
Also, I'm thinking if the repo_nonblockinglock could be a possible problem here. Depending on "how many webhooks we will receive" on different situations. For example, what happen if the user does:
git push --tags
which will make a push (sending new commits and new tags). Will this trigger one PUSH and one CREATE events? What if the user is pushing more than one tag? This could cause a problem when building because if the sync_versions is executed first by celery, then the update_docs_task will be locked.
This is something to be considered. I'm not sure this is a real problem, though
readthedocs/core/views/hooks.py
Outdated
| Due that `sync_repository_task` is bound to a version, | ||
| we always pass the latest version. | ||
|
|
||
| :returns: The version that was used to trigger the clone (usually latest). |
There was a problem hiding this comment.
Returns the version slug.
You can use :rtype: string also here.
readthedocs/core/views/hooks.py
Outdated
| """ | ||
| try: | ||
| version_slug = LATEST | ||
| version = project.versions.get(slug=version_slug) |
There was a problem hiding this comment.
Won't this fail for users that override the latest version?
I don't remember exactly, but I think there was also a way to disable latest, right?
There was a problem hiding this comment.
Yup, I was considering using the default branch here instead.
I have tested this locally, and works well becuase the push step doesn't trigger a new build (the new version doesn't exists!), so only the create event triggers a the sync. Here are some responses from my webhook when testing that
When pushing several versions, that would trigger several syncs, but the sync is really quick compared to the time that takes a full build, and I don't think we are going to experiment this very often, also, the current implementation has the same problem (when pushing several commits to master). And we are protected by the services, for example, from the github docs:
|
|
I had added some docs and comments, and also I'm using the default_branch rather than using LATEST. |
Closes #4450
Still wip, I need to write some tests, but I tested the GitHub integration with ngrok, and it works really good.
TODO