Agoric / agoric-sdk

monorepo for the Agoric Javascript smart contract platform
Apache License 2.0
327 stars 207 forks source link

Ability to merge "dev release" branches without up-to-date checks #9490

Open mhofman opened 5 months ago

mhofman commented 5 months ago

What is the Problem Being Solved?

"dev release" branches are protected to require up to date PRs (to maintain our mostly linear-ish history), However with switching to releasing from master, we need the ability to synchronize a dev-release and master branches:

Both require a merge with a branch that is not up-to-date. The latter might actually require a manual merge that may have conflicts and ignores some changes.

Description of the Design

Either

In either case, it requires mergify to be enabled on dev release branches, partially described in https://github.com/Agoric/agoric-sdk/issues/9920

Security Considerations

The current alternative requires to let admins bypass checks, and have an admin do manual merges. This is harder to audit.

Scaling Considerations

See above about admins needed without this

Test Plan

We have the mergify-experiments repo to get the config right before modifying agoric-sdk

Upgrade Considerations

None

rabi-siddique commented 3 months ago

with switching to releasing from master, we need the ability to synchronize a dev-release and master branches:

@mhofman Could you explain how we handle the release process? I'm a bit confused by the different branches like dev-release and upgrades. Is there a document that outlines all the steps? Your guidance would be really helpful.

rabi-siddique commented 3 months ago

When new changes on master need to be brought into the dev release work.

Will this be triggered by a label, similar to how we trigger merges in pull requests? Or should it automatically detect updates in the master and apply them to the dev release branch?

Also, how frequently do we anticipate needing to sync changes between the master and dev release branches?

mhofman commented 3 months ago

I expect this to be a manual workflow right now, whenever we are actively preparing a release. Most likely create a PR that uses automerge:no-update but with a specific label allowing it to skip "up to date" conditions.

mhofman commented 2 months ago

One flow that a "PR" based flow wouldn't support is to update the community-dev branch after a release. That must be a force-push to the recently tagged release. Even if we "merged" releases back into master, a PR wouldn't work to update that branch as there is no GH flow that "merges" a PR by fast forward. At best we could have mergify perform the forced update (or fast forward), and close the PR without using GH.