Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support shifting commits into branches without PR #926

Open
xmo-odoo opened this issue Aug 7, 2024 · 1 comment
Open

Support shifting commits into branches without PR #926

xmo-odoo opened this issue Aug 7, 2024 · 1 comment
Labels

Comments

@xmo-odoo
Copy link
Collaborator

xmo-odoo commented Aug 7, 2024

Suggestion of @Xavier-Do after transifex was mean again (kept pushing to 15.0 and 16.0 yesterday and thus cancelled essentially every staging): for the safer stuff like transifex, rather than require a full blown PR the mergebot could have a queue of commits to cherrypick, which it would simply shift into stagings. Two options were considered:

  • shift in / add those commits when creating the staging, the advantage is that those commits would be tested, the drawback is that it's hard to decide what would happen if the staging fails, whether because of a false positive or because the commit happens to be broken (which has happened once or twice w/ transifex but is really uncommon all things considered)
  • shift in after the staging, just before pushing to the reference branch, this reduces the delay if there's already a staging going on, but only if the staging is successful
  • or a combination of the two: just before / after checking if there's stuff to stage but separately, shift all the commits into the upstream branch directly, then do the staging

The latter seems like it combines all the advantages of the other two, and limits the drawbacks, and can furthermore allow immediate updates by cancelling the current staging for the branch (thus limiting the risks of conflicts). Eventually it could also allow suppressing the runbot build because e.g. it's not super useful to create a runbot build just because we merged translations.

TBD: how to tell the mergebot about those commits? Backend UI? API? Other?

/cc @d-fence @mart-e @beledouxdenis

A patch version should be supported for convenience / scripting, even though it will require working copies / worktrees after we managed to expunge them from the mergebot (neither git am nor git apply support applying patches to git trees, sadly).

@xmo-odoo xmo-odoo added this to Mergebot Aug 7, 2024
@xmo-odoo xmo-odoo moved this to ideas in Mergebot Aug 7, 2024
@xmo-odoo xmo-odoo changed the title Support shifting commits onto stagings without PR Support shifting commits into branches without PR Aug 7, 2024
@Xavier-Do
Copy link
Contributor

Xavier-Do commented Aug 7, 2024

TBD: how to tell the mergebot about those commits? Backend UI? API? Other?

-> backend ui in all cases, api via rpc calls? or maybe add a token authentication for simplicity?

@xmo-odoo xmo-odoo moved this from accepted to done in Mergebot Oct 3, 2024
xmo-odoo added a commit that referenced this issue Oct 22, 2024
Unstaged changes can be useful or necessary for some tasks
e.g. absolute emergency (where even faking the state of a staging is
not really desirable, if that's even possible anymore), or changes
which are so broad they're difficult to stage (e.g. t10s updates).

Add a new object which serves as a queue for patch to direct-apply,
with support for either text patches (udiff style out of git show or
format-patch) or commits to cherry-pick. In the former case, the part
of the show / format-patch before the diff itself is used for the
commit metadata (author, committer, dates, message) whereas for the
commit version the commit itself is reused as-is.

Applied patches are simply disabled for traceability.

Fixes #926
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: done
Development

No branches or pull requests

2 participants