build_packages is slow while CQ is failing |
||||
Issue descriptionA CQ run may submit changes partially even when the build as a while failed if test failures are not related to those changes. However, A CQ run publishes a binhost change ONLY IF the build as a whole succeeds. Due to this behavior, while CQ is red, contents of binhost gets more and more stale, which forces more packages to be built locally in build_packages. Note that this is problematic in combination with following other issues: 1. These days CQ is not very stable and it's not surprising to see it's red for several days. 2. Some packages are uprev'ed even if no change directly touches them. For example chromeos-base/modem-utilities was uprev'ed 288 times in last 5 months, while platform2/modem-utilities was changed only 2 times this year.
,
Feb 8 2018
we have a wolf-tot-paladin already. there's no reason it couldn't publish the binpkgs it produced for its host sdk whenever that phase passed.
,
Feb 8 2018
Indeed, making wolf-tot-paladin upload host package prebuilts will help. What about target packages? It sounds like not very easy to selectively publish binary packages which passed CQ...
,
Feb 8 2018
most binpkgs can be satisfied by the generics, so if we added an {arm,amd64}-generic-tot config, that would prob give decent coverage
alternatively, we could change our existing public incremental bots (not in the CQ) to upload their prebuilts ...
,
May 17 2018
,
Jul 13
|
||||
►
Sign in to add a comment |
||||
Comment 1 by nya@chromium.org
, Feb 8 2018