search

mozilla / release-services

Mozilla Release Engineering Services
https://docs.mozilla-releng.net
Mozilla Public License 2.0
49 stars 93 forks source link

Big Phabricator stack fail to apply #2100

Closed La0 closed 5 years ago

La0 commented 5 years ago

A revision with a big stack fail to apply, pulselistener behaves accordingly and posts a failed unit test

Maybe some landed patches are applied, and give a conflict ?

La0 commented 5 years ago

The full stack applied cleanly until the last patch. Here is the papertrail log

Edit: I reproduce the bug locally :cry: I'm now looking into the reason (might be because we do not test if a patch in the stack is already available on the local repo)

La0 commented 5 years ago

The stack is applied on base commit 8c0a7e7ccb508dabf38dd17f66aa93bed01c0754 as this revision is found as the base of the first patch on Phabricator PHID-DIFF-mugxlbeyyulfonpdf5gl

But this revision on mozilla-central misses dom/ipc/BrowserChild.h that the patch n°19 modifies (hence the build error).

That would imply we do not use the right base revision for that case...

Edit: the patch's developper confirmed on Slack that all previous patches are merged on M-C, so the bot should check if the patch has landed, and use the latest m-c revision instead

marco-c commented 5 years ago

This is a mistake by the developer in the end, as his patch is not based on the right revision.

La0 commented 5 years ago

Yes and No .... There is no way (that i know of) to update the base revision of the first patch in a stack. So if you want to keep working on a stack, but your earlier patches land, you can't do much to help us

marco-c commented 5 years ago

The right way would be for them to rebase the first patch in the stack that hasn't landed yet on top of latest mozilla-central. They are going to have to do it anyways, as otherwise they won't be able to land the patch.

marco-c commented 5 years ago

The right way would be for them to rebase the first patch in the stack that hasn't landed yet on top of latest mozilla-central

Which they have to do locally too, otherwise their patch won't even build!

La0 commented 5 years ago

That's exactly what he did (rebase on top of MC). It's just that the bot has not that information and use a deprecated information.

@Callek also got bitten by the same issue here

marco-c commented 5 years ago

This seems like an issue in moz-phab then? Why didn't it update the base revision of the patch?

La0 commented 5 years ago

I made a simple patch that stops loading the stack once a base revision is found in the repository.

The original revision from this issue applies with this patch