653041 - HgPoller should have a maximum number of changes

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Chris AtLee [:catlee]]

In bug 653029, we had around 60k new changes that got pulled in from the refresh of the mozilla-beta repo. It took a long time to process all those changes.

20:38 < dustin|gone> so I think the gitpoller now has a limit at which point it says "and some other changes" and doesn't read them
20:38 < catlee> but yeah, making the poller do that makes sense

would be better if HgPoller had an upper bound on how many changes it returns at once. Is the only reason we don't do something like tipsonly for non-try is so that we trigger jobs for individual pushes that happen between polls?

Comment 1

[Chris AtLee [:catlee]]

Attachment: Implement maxChanges

This patch makes it so the poller adds at most 100 changes every time it polls. This should be enough for most normal pushes, and protects us against insane pushes of entire repos.

It also exposes the repo_branch variable so that the try poller can pay attention to all branches instead of just default.

Comment 2

[Rail Aliiev [:rail]]

Comment on attachment 528854 [details] [diff] [review]
Implement maxChanges

Looks good.

Comment 3

[Chris AtLee [:catlee]]

Attachment: Implement maxChanges, and use tipsonly

Same as before, just with enabling tipsonly. Not sure which one we should land yet.