1963786 - code-review-bot couldn't find the base revision of a revision submitted with `MOZILLACENTRAL` as the base

Status: RESOLVED FIXED

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

moz-phab version (from moz-phab version): 1.8.1

Bug 1963595 changed the default repository for submissions to Phabricator to be FIREFOXAUTOLAND.

User :Standard8 submitted a patch while autoland was broken: https://phabricator.services.mozilla.com/D247337

Code Review Bot used the setup and inherited the broken Gecko Decision Task.

By default, Lando should use mozilla-central as base repository.

Comment 1

[Mark Banner (:standard8)]

(In reply to Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout) from comment #0)

Bug 1963595 changed the default repository for submissions to Phabricator to be FIREFOXAUTOLAND.

User :Standard8 submitted a patch while autoland was broken: https://phabricator.services.mozilla.com/D247337

To clarify, the submission that failed was submitted with MOZILLACENTRAL as the base. So the automation couldn't find the base revision (I assume as it was looking to base on git), and then seemed to default to autoland, rather than the mozilla-central base repo.

Comment 2

[Mark Banner (:standard8)]

I think it is slightly worse that what we previously thought. I think what it is running is variable... (maybe the tip of mozilla-unified).

For example, my push here was flagged as not applying because the files didn't exist. Looking at the log, it mentions this:

robustcheckout (err): (remote resolved tip to 2f1504b705ccdb95321f99b340e32be91d9599c2; result is not deterministic)

It looks like it then tries to check out the right thing, but I guess fails because it isn't git.

The revision above is a mozilla-beta-only commit, which is why the patch didn't apply - because the files aren't there yet.

The first patch in the stack also got applied to mozilla-beta, but because it touched files that were already there, it applied fine, but the tests will be running against out of date code/test harnesses.

Should this be tracked somewhere as part of the hg->git work?

Comment 3

[:glob ✱]

None of this appears to be an issue with moz-phab, and the bug's description isn't very clear. Generally it's best to file a bug that describes the problem, rather than just proposing a solution.

Let me see if I can untangle this .

• https://phabricator.services.mozilla.com/D247337 was created without issue targeting autoland

• code-review-bot failed to find the base revision (https://phabricator.services.mozilla.com/B784324); I believe this is expected right now, the code-review-bot folk are working on a fix

• https://phabricator.services.mozilla.com/D248131, a completely different revision, was created without issue targeting autoland

• code-review-bot failed to file files (eg. tools/@types/generated/tspaths.json)

• perhaps because the repo this was pushed to was autoland, while comment 2 seems to indicate it should have targeted beta?

So I think the issue this bug is reporting is "code-review-bot failed to apply the patches for D247337 and D248131"?

Should this be tracked somewhere as part of the hg->git work?

I've attached it to our main tracking bug for now.

Comment 4

[Mark Banner (:standard8)]

Sorry, I agree this has gotten a bit of a mess. Here's some hopefully clearer steps to repeat:

1. Create a patch locally, in a pure git repository, based off the latest main branch of mozilla-firefox/firefox.
2. Submit the patch to Phabricator.
3. Wait for the code review bot automation to run.
4. Inspect where the code review bot has applied the patch.

Expected Results

• As I based off of the main branch of mozilla-firefox/firefox, the code review automation run should either be based on the revision I was based on, or the latest main.
• The test results should always be consistent for the same patch which is pushed at different times (assuming the test mechanisms haven't been updated in-between).

Actual Results

• The patches have been applied to the mercurial "tip" of the mozilla-unified repository. Depending on when you push, and what has been pushed recently, this might be the tips of any of the active branches (autoland/central/beta/release/esr128/esr115).
• Depending on what you've submitted, and the timing, you may get:
  • failures to apply patches
  • incorrect results from the code review automation
• Resubmitting the same patch, may or may not clear the issues depending on if mozilla-unified has been pushed to and therefore may have switched to a different 'tip'.

Comment 5

[:glob ✱]

Thanks - this looks like a code-review-bot issue, moving.

Comment 6

[Marco Castelluccio [:marco]]

I think I've fixed this today.

Comment 7

[Mark Banner (:standard8)]

Thanks, as far as I can tell this does indeed appear to be fixed.