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
Limit concurrency in translations #6969
Conversation
It happens that projects using the same repository for all their translations will trigger multiple builds on each commit. Adding this concurrency limitation here helps us to protect ourselves when this happens.
6349a2d
to
a31a81a
Compare
This logic is missing from the trigger_build checking I think. We should add a single place where we query this logic.
We also need to treat translations as different than the main project. Otherwise if you trigger 50 translations that take 10 minutes each, it will take 250 minutes just to process them at 2x concurrency, which is...not great.
This logic is missing from the trigger_build checking I think. We should add a single place where we query this logic.
We also need to treat translations as different than the main project. Otherwise if you trigger 50 translations that take 10 minutes each, it will take 250 minutes just to process them at 2x concurrency, which is...not great.
Move the logic for the APIv2 running endpoint and `prepare_build` into one place: BuildQuerySet, to share the logic all over the code and be able to extend it if needed from corporate. `/api/v2/running/` now returns, - limit reached - concurrent builds - max concurrent builds allowed New logic also count translations as part of the concurrency allowed.
@ericholscher I put the logic all in one place ( I think the logic for the translations is correct and will make more sense once we have the priority queues, but we can adapt it as we wish there if needed. I currently counts "main + translations" as a whole. |
Even if we don't want the logic around limiting translations builds (which is easy to adapt/remove), the refactor around the code to put all the login in one place is still valid/good. |
I've come around on this being needed. Godot is killing our servers, and the priority celery stuff isn't working well, so I think this is the next best option.
…humitos/limit-concurrency-translations
It happens that projects using the same repository for all their translations
will trigger multiple builds on each commit. Adding this concurrency limitation
here helps us to protect ourselves when this happens.