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
{{ message }}
This repository has been archived by the owner on Oct 11, 2023. It is now read-only.
To work around "Risk of desynchronization for merge failures" problem outlined in #327, which is, quoted:
Risk of desynchronization for merge failures
Since the Substrate PR introduces breaking changes for Polkadot, should the Polkadot companion failed to be merged, because the Substrate PR is merged first (and we hope that the Polkadot one will be merged soon after), all future Substrate PRs could be blocked until the companion is merged because Polkadot master does not yet have the code to keep up with the Substrate PR's changes.
The solution mentioned there can be implemented
Solution: Implement a merge queue in processbot in order to prevent PRs without companions from being merged until PRs which have a companion are merged.
For this queue to work properly regarding companions, we'll need to get rid of the "ahead-of-time merge" behavior described in #327, that is, we'll wait until both sides (dependencies and dependents) are passing, instead of merging the dependency first and then the dependents. It would work as follows:
Receive bot merge on Substrate
Update Cargo.lock on Polkadot
Put the merge in the queue (of course this also takes into account the companion(s))
Wait until both are passing (restore the code of 271f265)
Merge both simultaneously
When updating the Cargo.lock file, first we'll probably need to create a tag on Substrate for the Substrate PR so that its head SHA is kept available in the repository and therefore can be referenced on Polkadot. To make it clear why this is relevant, we can not update Substrate's reference on Polkadot using the PR's head because it might come from an external repository and so we don't have a guarantee that the referenced SHA would be available indefinitely - creating tags on Substrate would be a way to guarantee that.
This implementation might fix #236 partially or totally; this should be verified when/if this ticket gets implemented.
To work around "Risk of desynchronization for merge failures" problem outlined in #327, which is, quoted:
The solution mentioned there can be implemented
For this queue to work properly regarding companions, we'll need to get rid of the "ahead-of-time merge" behavior described in #327, that is, we'll wait until both sides (dependencies and dependents) are passing, instead of merging the dependency first and then the dependents. It would work as follows:
bot merge
on SubstrateWhen updating the Cargo.lock file, first we'll probably need to create a tag on Substrate for the Substrate PR so that its head SHA is kept available in the repository and therefore can be referenced on Polkadot. To make it clear why this is relevant, we can not update Substrate's reference on Polkadot using the PR's head because it might come from an external repository and so we don't have a guarantee that the referenced SHA would be available indefinitely - creating tags on Substrate would be a way to guarantee that.
This implementation might fix #236 partially or totally; this should be verified when/if this ticket gets implemented.
We can also provide a queue visualization tool such as https://bors.rust-lang.org/queue/rust.
The text was updated successfully, but these errors were encountered: