You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the mergebot assumes each branch only has one staging going on, and this assumption is leveraged in several places (usually by checking a branch's active_staging_id for information).
This is likely non-trivial, but would be a requirement for advanced staging modes e.g.
optimistic concurrent staging (create staging 2 on top of staging 1 if there are enough PRs waiting)
concurrent split staging (Stage concurrent splits #497) as well as pessimistic concurrent staging (the same without a split, assumes the current staging is going to fail)
pessimistic splitting (stages a staging and its splits at the same time such that one of the splits can be merged if the main staging fails)
...
Changing this would likely require some sort of intermediate staging strategy object, which can bundle a bunch of stagings and provides relevant query operations. Note that this also impacts batches and PRs as we dereference their stagings e.g. to cancel the current staging if they're part of that on r- or w/e.
The text was updated successfully, but these errors were encountered:
Currently the mergebot assumes each branch only has one staging going on, and this assumption is leveraged in several places (usually by checking a branch's
active_staging_id
for information).This is likely non-trivial, but would be a requirement for advanced staging modes e.g.
Changing this would likely require some sort of intermediate staging strategy object, which can bundle a bunch of stagings and provides relevant query operations. Note that this also impacts batches and PRs as we dereference their stagings e.g. to cancel the current staging if they're part of that on r- or w/e.
The text was updated successfully, but these errors were encountered: