Sleep even less between polling for MRs #75
Conversation
marge/bot.py
Outdated
| time.sleep(time_to_sleep_between_projects_in_secs) | ||
| time.sleep(max(0, | ||
| min_time_to_sleep_after_iterating_all_projects - | ||
| time_to_sleep_between_projects_in_secs * len(filtered_projects))) |
There was a problem hiding this comment.
@aschmolck As it is, we are going to let the user know that marge is about to sleep for 1 sec, and fail to log anything when sleeping for 30 secs. This should be the other way round.
aschmolck
force-pushed
the
even-less-drowsy
branch
from
f118b02 to
19f180d
Compare
The logic is: we want to sleep at least 30 secs after iterating over all projects (both so that people have a chance to undo accidental assignments to marge and to not poll like crazy when nothing is happening to the repo). If there are many projects, the current system sleeps too long, though. Let's just sleep one sec between each by default and then make up the difference to the 30s afterwards.
aschmolck
force-pushed
the
even-less-drowsy
branch
from
19f180d to
9f70c5c
Compare
|
@aschmolck I think travis works now without deprecated set |
mrusu91
force-pushed
the
even-less-drowsy
branch
from
1351d34 to
9f70c5c
Compare
|
i was thinking too when first installed marge-bot. i.e does make difference how marge is project member... what do you suggest? assign bot to group or every project manually. is there any difference? |
|
With this change, it shouldn't make a huge difference difference how many projects can be accessed. Assigning marge to projects / groups should be a matter of admin preference, I think |
|
btw, if i look at marge's log, it makes api calls to each project. perhaps gitlab can have api call to give "all mr's i'm assigned to", any attempt to make feature request to gitlab-org? |
|
There seems to be indeed such an endpoint since 9.5: https://docs.gitlab.com/ee/api/merge_requests.html#list-merge-requests Since we want to ensure that no project starves another one, to use this endpoint we'd have to fetch all pages for this request, pick the oldest per project and iterate over those. Still, between merge requests, we need to check that next merge request we are to process is still assigned to us, etc. I'm not sure it will make a significant difference, but if anyone wants to give it a go, I'd be happy to review a PR. |
In order to enable bot derived class to launch different kind of jobs.
The logic is: we want to sleep at least 30 secs after iterating over all
projects (both so that people have a chance to undo accidental assignments to
marge and to not poll like crazy when nothing is happening to the repo). If
there are many projects, the current system sleeps too long, though. Let's just
sleep one sec between each by default and then make up the difference to the 30s
afterwards.