Chrome CQ should do official Chrome OS builds |
|||
Issue descriptionLast Friday (2018-11-30), two different Chrome changes caused Assistant-related build failures in the Chrome PFQ builders that are used to integrate new releases of Chrome into Chrome OS. https://crrev.com/c/1356312 introduced a typo in chromeos/services/assistant/audio_decoder/assistant_audio_decoder_service.cc. This caused failures in the ToT informational PFQ builders, e.g. http://cros-goldeneye/chromeos/healthmonitoring/buildDetails?buildbucketId=8928371933715353664. https://crrev.com/i/723309 caused a build failure due to a broken dependency in //chromeos/services/assistant/BUILD.gn pointing at //chromeos/assistant/internal/action. See issue 910826 . Ken indicated in https://crrev.com/c/1357670 that we don't have Chrome CQ coverage for official Chrome OS builds. Is there a builder that would've caught both of these issues before they went into Chrome? If so, can we add it to the Chrome CQ? I'm anxious if we really don't have any coverage for Assistant-related changes.
,
Dec 4
It's not on the CQ, but we do have a main waterfall bot that builds official cros: https://luci-milo.appspot.com/buildbot/chromium.chrome/Google%20Chrome%20ChromeOS It did fail when https://crrev.com/c/1356312 landed: https://luci-milo.appspot.com/buildbot/chromium.chrome/Google%20Chrome%20ChromeOS/59213 And rolled green w/ the revert: https://luci-milo.appspot.com/buildbot/chromium.chrome/Google%20Chrome%20ChromeOS/59216 And also failed when https://crrev.com/i/723309 was rolled into src in http://crrev.com/c/1357422: https://luci-milo.appspot.com/buildbot/chromium.chrome/Google%20Chrome%20ChromeOS/59205 And was subsequently fixed w/ http://crrev.com/c/1356326 (I think): https://luci-milo.appspot.com/buildbot/chromium.chrome/Google%20Chrome%20ChromeOS/59209 Given that the bots on that waterfall are sufficiently sheriffed (I think), and that we can't put official builds on the CQ like Dirk said, I think this is a wontfix?
,
Dec 4
Yes, I think the Assistant code is private. I didn't realize that we can't build private code on the CQ. Are there any plans to change that in the future? Even if broken changes get reverted by sheriffs, they can still find their way into the nightly branches used by the Chrome PFQ before that happens. Is it possible to prevent that from happening somehow?
,
Dec 4
We don't have concrete plans to change this at the moment, but we think about it a lot and may change it in the future. The biggest problem is probably that if something is an internal build, then we can't reveal the results of the build to non-Googlers. So, you'd get told that your change broke something, but not what, and that's obviously frustrating. Of course, arguably you'll be told that later anyway. We also would need to get really better at monitoring the internal build failures than we are now (e.g., get them properly integrated into Sheriff-o-matic). This part we definitely plan to fix as soon as we can. Lastly, some might object on philosophical grounds that we shouldn't be gating commits to a public project on non-public things, but I don't know if anyone would be that seriously upset by this. There are also some practical things related to ACLs, etc. in the infrastructure we'd have to work out, and doing that largely will require us to be completely migrated over to LUCI, which we're not quite done with yet. We are talking about other things we can do to improve how the PFQ works, and there's probably more opportunity for stuff we can fix sooner there.
,
Dec 4
Thanks for the detailed explanation. Looking forward to seeing the other improvements! :-) |
|||
►
Sign in to add a comment |
|||
Comment 1 by dpranke@chromium.org
, Dec 4