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

Merge using comments #1355

Open
rarkins opened this issue Jan 8, 2018 · 24 comments
Open

Merge using comments #1355

rarkins opened this issue Jan 8, 2018 · 24 comments
Labels
priority-4-low Low priority, unlikely to be done unless it becomes important to more people status:blocked Issue is blocked by another issue or external requirement type:feature Feature (new functionality)

Comments

@rarkins
Copy link
Collaborator

rarkins commented Jan 8, 2018

Scenario:

  • Repository has 5 Renovate PRs
  • All 5 pass tests, and look OK to a reviewer
  • Reviewer wants to merge them all "right away", but:
  • To be safest, you should merge one, then rebase/retest the rest, then merge, then rebase/retest, etc

The result is that a reviewer/merger needs to keep checking back over a period of perhaps hours as they wait for tests to finish.

Solution:

  • users with write permissions can comment on each with "!merge"
  • Renovate will automatically merge them one by one, as it is able - allowing for rebases, retesting, etc

Inspiration: https://github.com/uber-workflow/probot-app-merge-pr

@rarkins rarkins added type:feature Feature (new functionality) priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others ready labels Jan 8, 2018
@rarkins
Copy link
Collaborator Author

rarkins commented Jan 8, 2018

To the Algolia team e.g. @samouss and @Haroenv, I often see you merging multiple PRs close together. Would this approach save you time? e.g. you manually review the PRs in a batch and add a comment "!merge" to each that is OK. Renovate will then merge them as fast as is possible allowing for any necessary conflict resolving, rebasing, retesting, etc.

@Haroenv
Copy link

Haroenv commented Jan 8, 2018

I'd like it more if a review would do this, rather than !merge, is that possible?

@rarkins
Copy link
Collaborator Author

rarkins commented Jan 8, 2018

It's possible today, although perhaps with some warning.

First of all, how that would work:

  • You would configure Renovate with automerge enabled, perhaps even for all PRs including major.
  • You would enable branch protection such that Reviews are required before merging. This will "block" automerge by default
  • If a Renovate PR is reviewed and other tests have passed, then GitHub will turn it green. This will allow Renovate to automerge it

The warning is that maybe:

  • The person reviewing it does not mean "merge this!". They maybe mean "looks ok to me" but assume someone else will look as well
  • Maybe the person reviewing should not be authorised to approve a merge

@Haroenv
Copy link

Haroenv commented Jan 8, 2018

Those are good points, is there some way to check if reviewer can merge?

@rarkins
Copy link
Collaborator Author

rarkins commented Jan 8, 2018

If you have restricted who can merge to master in the repo (e.g. in branch protection settings you have listed individuals or teams with merge rights) then unfortunately Renovate cannot merge. This is because of a GitHub bug/limitation where they don't offer any way to add an app (bot) to that list so all apps get blocked from merging if you enable that type of branch protection.

Otherwise, if you just mean users with write access to the repository vs read-only, then we can probably look that up. Please confirm if that's what you mean or if it's something else.

@rarkins
Copy link
Collaborator Author

rarkins commented Jan 8, 2018

Maybe.. we could also add a new config option to renovate's config that lets you define which users should merge if they review/approve the PR.

@ghost
Copy link

ghost commented Jan 9, 2018

I like the idea of using built-in functionality (reviewers) of the GitHub interface for this workflow.

(I use the merge when pipeline succeeds feature in GitLab quite often to help queue up merge requests when several come in at once)

@rarkins rarkins added priority-4-low Low priority, unlikely to be done unless it becomes important to more people and removed priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others labels Jan 15, 2018
@rarkins rarkins added help wanted Help is needed or welcomed on this issue needs-requirements and removed ready labels Apr 1, 2018
@rarkins

This comment has been minimized.

@rarkins rarkins closed this as completed Jul 24, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 15, 2020
@renovatebot renovatebot unlocked this conversation Dec 16, 2020
@rarkins rarkins reopened this Dec 16, 2020
@rarkins
Copy link
Collaborator Author

rarkins commented Dec 16, 2020

Reopening to add this comment by @azu in #3172:

Merge via comment is useful for me.
GitHub/GitLab supports commenting via email and I can merge the dependabot's PR from email client like gmail.

UseCase: renovatebot/dependabot create same Pull Request to multiple repositories at same time.
It is hard that open each PRs and click merge button.
Instead of it, I can just reply @dependabot merge from email client.

image

checkbox approach may not cover this case.

@rarkins rarkins added the status:requirements Full requirements are not yet known, so implementation should not be started label Jan 12, 2021
@rarkins
Copy link
Collaborator Author

rarkins commented Aug 8, 2021

GitHub's native automerge feature is a viable and someway better workaround for this

@anantakrishna
Copy link

GitHub's native automerge feature is a viable and someway better workaround for this

Can you please give a link? I cannot find this feature by googling.

@rarkins
Copy link
Collaborator Author

rarkins commented Aug 8, 2021

Google for "GitHub automerge"

@anantakrishna
Copy link

Thanks, and excuse me for a bit of laziness. I was searching for “GitHub's native automerge feature”, and mostly only Dependabot-related articles came up.

Here is the link for future strangers: https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request

@rushilsrivastava
Copy link

Wanted to jump in here and provide an additional use case for merge using comments. We use Poetry to manage our Python dependencies, which breaks the lock file each time one dependency is updated. This means that there is a lot of time one has to wait before merging in a subsequent dependency (i.e. wait for a rebase with the correct lock file). It would be really convenient to have a "rebase & merge" comment option.

@rarkins
Copy link
Collaborator Author

rarkins commented Oct 15, 2021

Which platform/hosting mode are you using?

@rushilsrivastava
Copy link

Which platform/hosting mode are you using?

We use the GitHub App.

@rarkins
Copy link
Collaborator Author

rarkins commented Oct 15, 2021

Rebasing should happen automatically in the GitHub app without requiring manual intervention. Please create a separate discussion topic if you're not seeing that and can provide some logs or other evidence to help pinpoint it

@rushilsrivastava
Copy link

rushilsrivastava commented Oct 15, 2021

Rebasing should happen automatically in the GitHub app without requiring manual intervention. Please create a separate discussion topic if you're not seeing that and can provide some logs or other evidence to help pinpoint it

Rebasing does happen automatically, it just takes a significant amount of time using Poetry (Between 10-15 minutes if manually triggered, 25-30 minutes if automatic). I can open another discussion topic, but I don't think this is a limitation in Renovate, but with Poetry itself. We had a similar problem on Dependabot, but having the rebase and merge problem made it easy to handle.

@rarkins
Copy link
Collaborator Author

rarkins commented Oct 15, 2021

Poetry may be slow and that's not Renovate's fault, but the following should be false:

(Between 10-15 minutes if manually triggered, 25-30 minutes if automatic)

Automatic rebasing should happen as fast/faster than you can achieve with manual, because the merging of any Renovate PR should trigger a priority job in the queue.

I would have hoped that if you enable GitHub automerge in each PR and just leave them you should see them rebased until they are all merged (or failing tests).

@Inok
Copy link

Inok commented Sep 27, 2022

Such "semi-auto" merge will be useful. In my case, I don't want to merge everything manually, but I want to review the changelog of the package being updated and changes in my source code before merging them.

Maybe it's possible to add an option that enables such "semi-auto" flow? For example, by adding a new checkbox to PRs? (like force rebase checkbox)
If it's checked, Renovate will try to rebase/merge the PR automatically. If it's not - Renovate will wait for confirmation.

So automerge option may be changed from a boolean flag to something like:

  • enabled - current automerge=true
  • suggested - disabled until the checkbox is checked, then enabled
  • disabled - current automerge=false

Or simply add automergeType=pr-with-confirmation, which enables such behavior.

@rarkins
Copy link
Collaborator Author

rarkins commented Sep 28, 2022

automergeType=checkbox might make most sense

@HonkingGoose
Copy link
Collaborator

@rarkins said they want to do the linked issue first: 1

I'll mark this issue status:blocked. After we've tried the checkbox-approach, we'll decide if we want to work on this issue. 😉

Footnotes

  1. https://github.com/renovatebot/renovate/discussions/20166#discussioncomment-4852270

@HonkingGoose HonkingGoose added status:blocked Issue is blocked by another issue or external requirement and removed help wanted Help is needed or welcomed on this issue status:requirements Full requirements are not yet known, so implementation should not be started labels Feb 13, 2023
@HonkingGoose
Copy link
Collaborator

HonkingGoose commented Jul 20, 2023

Related discussion:

@HonkingGoose
Copy link
Collaborator

Summary

How about prioritizing:

And closing these issues/discussions as won't do:

That way the bulk of users have a good way to speed up the "merge multiple Renovate PRs" workflow.

Why we opened this issue

This is the problem we wanted to solve by making a new "merge using comments" feature:

Scenario:

  • Repository has 5 Renovate PRs
  • All 5 pass tests, and look OK to a reviewer
    -Reviewer wants to merge them all "right away", but:
  • To be safest, you should merge one, then rebase/retest the rest, then merge, then rebase/retest, etc

The result is that a reviewer/merger needs to keep checking back over a period of perhaps hours as they wait for tests to finish.

Changes since the issue was created

GitHub Merge Queue

GitHub now has Merge Queue, 1 where you can approve a PR, put it in the Queue, and let GitHub merge when the tests pass. GitHub will make sure the combination of PRs passes the tests. You can use GitHub Merge Queue with Renovate. 2

GitLab has Merge Trains (we don't support that yet)

We're going to a checkbox-based system?

I think, in general, we're going towards a checkbox-based system? See:

Difficult to verify comment is allowed to merge

If we want to keep this issue open, we still need to decide how to get Renovate to only accept merge comments from allowed users:

Footnotes

  1. GitHub Docs, managing a merge queue

  2. Renovate docs, GitHub Merge Queue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-4-low Low priority, unlikely to be done unless it becomes important to more people status:blocked Issue is blocked by another issue or external requirement type:feature Feature (new functionality)
Projects
None yet
Development

No branches or pull requests

6 participants