Closed Bug 1232738 Opened 6 years ago Closed 6 years ago

Autoland should use "internal:merge"

Categories

(MozReview Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mossop, Assigned: dminor)

Details

Attachments

(1 file)

I attempted an autoland with this review: https://reviewboard.mozilla.org/r/27677/

It failed to rebase so I rebased myself, pushed to review and then tried again. It failed again with this error::

We're sorry, Autoland could not rebase your commits for you automatically. Please manually rebase your commits and try again. hg error in cmd: hg rebase -s 84603e4d1109 -d ec86fd78c958: rebasing 296730:84603e4d1109 "Bug 1231828: Fix JS parsing errors in toolkit and browser XBL files. r=Felipe" (tip) unresolved conflicts (see hg resolve, then hg rebase --continue) 

I have no idea what source changeset it is using (84603e4d1109). That isn't the revision I pushed and doesn't appear in the review repository.

Rebasing my local changesets on tip of ec86fd78c958 worked with no conflicts so I don't know what code it was trying to rebase.
I believe what has happened is that you have r=felipe in your commit string, but the user name in MozReview is Felipe, so Autoland amended your commit message to be r=Felipe, which is where commit 84603e4d1109 came from.

I'll investigate why the rebase failed.
Component: Autoland → MozReview
Product: Tree Management → Developer Services
Target Milestone: --- → Future
Version: --- → unspecified
We set "merge = internal:fail" on autoland to prevent manual merges when autolanding.

If I run with this setting locally, the rebase fails as on autoland. If I run without this setting, I see "merging toolkit/content/jar.mn" in the output, but no manual merge is required, so it seems like this setting is too aggressive in preventing manual merges.

I recently overrode the default hglib behaviour to run a non-interactive session in autoland, so we might be able to remove "merge = internal:fail" now.
So, a file merge occurs when *any* part of the file changes, not just the part inside the patch/diff. I'm pretty sure internal:fail will cause all file merges to fast fail.

We want to use internal:merge. If there are conflicts, it will leave markers and abort and `hg resolve` will be required to mark files as resolved before continuing. This error should cause autoland to fail, which is the appropriate thing to happen in case of merge conflict (we want humans to resolve the problem).

We'll definitely want test coverage for file merge handling.
Assignee: nobody → dminor
Status: NEW → ASSIGNED
Summary: Autoland is trying to land the wrong thing → Autoland should use "internal:merge"
Comment on attachment 8698610 [details]
MozReview Request: autoland: use internal:merge (bug 1232738) r?gps

https://reviewboard.mozilla.org/r/28045/#review25119

There is plenty of room for follow-up work to improve the messaging on failure. It would be really nice if we could tell people exactly what command to run to perform the rebase, for example. But that can be deferred to another bug.
Attachment #8698610 - Flags: review?(gps) → review+
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: Future → ---
Product: Developer Services → MozReview
You need to log in before you can comment on or make changes to this bug.