mozilla/release-services

Big Phabricator stack fail to apply

Closed this issue · 9 comments

La0 commented

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

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

Edit: I reproduce the bug locally 😢
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

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

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

La0 commented

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

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.

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

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

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

La0 commented

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