CQ let a patch land that blocked subqequent commits |
|||||
Issue descriptionThe CQ let https://codereview.chromium.org/2924663003/ land but subsequent commits were failing with the error below. This is a really easy mistake to make in a patch and it would would be great if the CQ could catch it at the right time. """ to /b/build/slave/ios-device/build/src/out/Release-iphoneos/args.gn. /b/build/slave/ios-device/build/src/buildtools/mac/gn gen //out/Release-iphoneos --check -> returned 1 ERROR at //ios/chrome/browser/ui/payments/payment_request_mediator_unittest.mm:17:11: Can't include this header from here. #include "components/signin/core/browser/signin_manager.h" ^---------------------------------------------- The target: //ios/chrome/browser/ui/payments:unit_tests is including a file from the target: //components/signin/core/browser:browser It's usually best to depend directly on the destination target. In some cases, the destination target is considered a subcomponent of an intermediate target. In this case, the intermediate target should depend publicly on the destination to forward the ability to include headers. Dependency chain (there may also be others): //ios/chrome/browser/ui/payments:unit_tests --> //ios/chrome/browser/ui/payments:payments --[private]--> //components/signin/core/browser:browser E.g. https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Ftryserver.chromium.mac%2Fios-device%2F226891%2F%2B%2Frecipes%2Fsteps%2Fgenerate_build_files__mb___with_patch_%2F0%2Fstdout
,
Jun 7 2017
Since the error is in GN step, +dpranke@ do you know why it wasn't caught with the patch on tryjobs?
,
Jun 7 2017
https://chromium-review.googlesource.com/c/527072/ adds the dependencies. Will go ahead reland https://codereview.chromium.org/2924663003.
,
Jun 7 2017
strange, the ios-device build on the trybots succeeded: https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Ftryserver.chromium.mac%2Fios-device%2F226411%2F%2B%2Frecipes%2Fsteps%2Fgenerate_build_files__mb___with_patch_%2F0%2Fstdout Testing this patch locally, `gn check` fails (correctly) but `gn gen --check` is failing. I'm not sure what's going on, but this feels like a race in GN. brettw@, can you take a look?
,
Aug 18 2017
,
Mar 20 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by alexclarke@chromium.org
, Jun 7 2017