Since enabling unittests on the try server, the existing try-server pool-of-slaves has been getting more work to do. This is because:
- more people are using try server now
- each request to try server is doing more stuff (ie unittests-which-include-an-additional-build, in addition to the standalone builds!)
We had some spare capacity beforehand, so mac, linux have been keeping up, but win32 machines were not able to keep up. To clear the win32 backlog, this morning, we switched over 6 win32 slaves from the main production pool-of-slaves to try-server pool-of-slaves, to clear the win32 backlog.
We’ll move those slaves back to main production pool-of-slaves once the backlog is cleared, and the previously requested 4 additional try slaves are online (see bug#485883, bug#485885 for details).
This means that for a few hours today, we’ll have 6 fewer slaves on production pool-of-slaves, so some win32 jobs might take longer then usual. Please be patient. We’re hoping that we’ll have caught up on try-server backlog and returned these 6 win32 slaves in a few hours, so maybe it wont even be noticeable. If you do see problems, please let us know in bug#486672.
More later…
John.
Why do “try” and “production” use separate pools, instead of sharing a single pool (perhaps with priority tricks)?
[…] Quick followup after my last blogpost: […]