pfq-informational bots: change to using versioned manifests produced by the CQ |
|||
Issue descriptionRecently a CrOS change caused a pfq-information failure, but tracking down the CrOS change responsible was difficult because the change was not reflected in the Sync summary. Build A (did not fail in platform_AddPrinter): https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8934926624335735904 Full version R71-11081.0.0-b2958406 Build B (failed in platform_AddPrinter): https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8934904385793365792 Full version R71-11081.0.0-b2959209 Note: '2958406' and '2959209' are just the last digits of the buildbucketId It looks like the builder is just running 'repo sync' and not syncing to a specific manifest: 19:03:20: INFO: RunCommand: repo --time sync --force-sync '--cache-dir=/b/swarming/w/ir/cache/git' -l in /b/swarming/w/ir/cache/cbuild/repository Your sources have been sync'd successfully. real 0m5.979s <?xml version="1.0" encoding="UTF-8"?> <manifest revision="18135db6c840f504f8ee08264b9b751d9077ed10"> A bunch of projects changed from A to B, including the cluprit: <project groups="minilayout,firmware,labtools" name="chromiumos/overlays/chromiumos-overlay" path="src/third_party/chromiumos-overlay" revision="dbdd6487323c2d99261892d9bc8366036fa8f18b" sync-c="true" upstream="refs/heads/master"/> However identifying that difference was quite subtle + tedious / labor intensive. Questions: 1. Is 'repo sync' without specifying a manifest version entirely safe? 2. If so, is there a straightforward way to get the actual CrOS differences and display them in the Sync stage output?
,
Sep 20
Update: The pfq-informational builders generate a manifest.xml from tot for each repository. These are uploaded gstorage, so for the examples in the description: https://pantheon.corp.google.com/storage/browser/chromeos-image-archive/caroline-tot-chrome-pfq-informational/R71-11081.0.0-b2958406 https://pantheon.corp.google.com/storage/browser/chromeos-image-archive/caroline-tot-chrome-pfq-informational/R71-11081.0.0-b2959209 So currently, to find the changes to the packages, the manifest.xml file for each build needs to be downloaded then diffed, and the history for each diffed project needs to be examined.
,
Sep 20
Also, after chatting about this with dgarrett@ and vapier@, I think that the pfq-informational builders would actually be more valuable if they used the latest cq/rc manifest instead of "tot". Then we would at least be testing against a theoretically-good CrOS snapshot.
,
Sep 20
having it just use whatever the CQ has snapped off sounds fine. we don't even need to look at the CQ status since that won't really reflect the manifest version, but also all the CLs it tested.
,
Sep 20
We also discussed the possibility of using a pfq-informational-master to generate a tagged manifest file used across each slave (which would then be synchronized). Pros: * May be the easiest implementation * Easier to identify flake or device specific failures since multiple slaves would be testing the same set of changes. Cons: * Faster builders would run less frequently. * Out-of-sync builders can sometimes generate smaller diffs (but narrowing the bisect range that way is pretty tedious). |
|||
►
Sign in to add a comment |
|||
Comment 1 by jclinton@chromium.org
, Sep 20Status: Available (was: Untriaged)