This is an intermediate effort which should have less impact (be a lot easier to implement) on the mergebot while providing for easier evaluation of the possible benefits (and thus putting more thinking into developing a full solution, or rolling it back and going back to the drawing board): one of the things blocking #959 (its sub-issues) is the modelling complexity.
However the recent-ish "tree hash" update of the runbot offers a halfway solution: the mergebot can create sub-staging branches with the relevant content (commits) but not model that at all on its side, instead if / when it needs to create the relevant staging(s) the runbot should deduplicate the build and it will already have received the relevant statuses.
This could be used to:
- optimistically create the next staging IFF the current staging is full and there are more than 16 batches waiting (?)
- pessimistically create splits for the current staging
Of course this should be easy to enable/disable, maybe on a per-branch basis (as we'd probably mostly want to test / enable it on master).
This is an intermediate effort which should have less impact (be a lot easier to implement) on the mergebot while providing for easier evaluation of the possible benefits (and thus putting more thinking into developing a full solution, or rolling it back and going back to the drawing board): one of the things blocking #959 (its sub-issues) is the modelling complexity.
However the recent-ish "tree hash" update of the runbot offers a halfway solution: the mergebot can create sub-staging branches with the relevant content (commits) but not model that at all on its side, instead if / when it needs to create the relevant staging(s) the runbot should deduplicate the build and it will already have received the relevant statuses.
This could be used to:
Of course this should be easy to enable/disable, maybe on a per-branch basis (as we'd probably mostly want to test / enable it on master).