buildbot: merge portwatcher jobs

[mojca (Mojca Miklavec)]

When there are ten commits to the same port waiting in the job list for the port watcher, that port might be built ten times. (OK, in reality it would probably be skipped the other nine times.)

Port watcher already merges some jobs if they are committed simultaneously and that seems to work satisfactory. It would probably be OK if we would merge all jobs from the waiting list to a single portwatcher item.

(Feel free to argue and close this ticket if you disagree. I'm not sure if the benefit is really substantial in any way.)

[ryandesign (Ryan Carsten Schmidt)]

Is there a specific case where this was actually a problem?

If you already know in advance that you're going to commit several changes to the same port, you should push those changes all at once.

[mojca (Mojca Miklavec)]

This has never really been a problem, just a tiny optimisation suggestion. I had it on the list in the other "mega" ticket, so I wrote it down as a separate issue, but if there's consensus that this makes no sense, we can close it and ignore it.

This might make a difference when there is a long queue, so the timing window is longer. Someone spots a problem in a recent commit and fixes it.

I remember this would usually be the case when a build finished fast on one builder (and most likely failed), then I would try to fix the problem, commit, the build would still fail, I would commit a fix again etc. Meanwhile the commits kept accumulating on 10.5/ppc.

[ryandesign (Ryan Carsten Schmidt)]

Not sure why I was arguing about this; probably just trying to avoid working on it. I agree with you, we should reduce the number of unnecessary builds if we can.

I suppose we are only talking about merging builds in portwatcher queues. A portbuilder queue is expected to have multiple builds, one for each port; those can't be merged. There shouldn't ever be a time when a portbuilder queue has more than one pending build for a particular port. And we don't want to merge builds in a base queue; we want to build each base commit so that we can identify which commit introduced or fixed a problem.

This feature is now called ​collapseRequests. The concern would just be that we still need to build every port we're supposed to. And we need to be able to attach status information to the relevant GitHub commit.

For example, suppose that while a portwatcher is busy, a commit b comes in that modifies php, then a force-build request comes in for xz, then a commit c that modifies harfbuzz, then another commit d that modifies php, then a force-build comes in for fontconfig, and then the portwatcher that was busy finishes. If we collapse all of that activity into one portwatcher build, it still needs to trigger one portbuilder build for each of those ports and their subports. So, the list of files modified in the commits needs to be merged, and the contents of the portlist property needs to be merged. Not sure how much of that buildbot does for us automatically; would need to try it out. (As long as force-building only involves a portlist field this may work, but if we want to add additional force-build fields it becomes less clear how to combine them.) The build status for harfbuzz should still be attached to commit c, build status for php should be attached to commit d, and I think for the force builds we would not want to attach build status to any commit since those builds did not originate from commits.

[mojca (Mojca Miklavec)]

I would not try to mix and match force builds with regular commits. Just collapse those commits that came one after another into a single "port watcher" job (as if one developer had pushed everything to github at once).

[ryandesign (Ryan Carsten Schmidt)]

If that's what Buildbot ends up doing when I enable collapseRequests, great. I just don't know what it's going to do; haven't tried it yet.