Skip to content
This repository has been archived by the owner on Nov 11, 2019. It is now read-only.

Big Phabricator stack fail to apply #2100

Closed
La0 opened this issue May 13, 2019 · 9 comments · Fixed by #2105
Closed

Big Phabricator stack fail to apply #2100

La0 opened this issue May 13, 2019 · 9 comments · Fixed by #2105

Comments

@La0
Copy link
Contributor

La0 commented May 13, 2019

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
Copy link
Contributor Author

La0 commented May 14, 2019

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
Copy link
Contributor Author

La0 commented May 14, 2019

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
Copy link
Collaborator

marco-c commented May 14, 2019

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

@La0
Copy link
Contributor Author

La0 commented May 14, 2019

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
Copy link
Collaborator

marco-c commented May 14, 2019

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
Copy link
Collaborator

marco-c commented May 14, 2019

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
Copy link
Contributor Author

La0 commented May 14, 2019

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
Copy link
Collaborator

marco-c commented May 14, 2019

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

La0 pushed a commit to La0/mozilla-relengapi that referenced this issue May 14, 2019
@La0
Copy link
Contributor Author

La0 commented May 14, 2019

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

@La0 La0 closed this as completed in #2105 May 15, 2019
La0 added a commit that referenced this issue May 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants