Issue metadata
Sign in to add a comment
|
confirm no-op step not performed on the CQ |
||||||||||||||||||||||||
Issue descriptionWe had a failure that sneaked past the CQ due to the no-op step: https://uberchromegw.corp.google.com/i/chromium.win/builders/Win%20x64%20Builder/builds/34160 The change that caused this failure landed with green CQ bots: https://codereview.chromium.org/2940403002 This was fixed with a revert in: https://codereview.chromium.org/2951883002 Sadly, this affected many users (see chromium-dev thread or links in the original review). Is this something that could have been caught by the CQ?
,
Jun 22 2017
Yuzhu Shen posted on the chromium-dev thread: ------------------8<------------------ The issue is that I moved some files into a new target "safe_browsing". It included "gen/chrome/grit/generated_resources.h" but didn't depend on "//chrome/app:generated_resources". Whether a 2nd compilation is a no-op depends on whether the 1st compilation generates "generated_resources" before building "safe_browsing". That is non-deterministic. I think that is why it could pass the CQ. ------------------8<------------------
,
Jun 22 2017
We do actually run "confirm no-op" checks on most of the builders in the CQ.
,
Jul 31 2017
,
Jan 4 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by vadimsh@chromium.org
, Jun 22 2017Components: -Infra Infra>Platform>Recipes Infra>Client>Chrome