New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 807082 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature

Blocking:
issue 803693



Sign in to add a comment

Enable incremental InitSDK in Pre-CQs

Project Member Reported by nxia@chromium.org, Jan 30 2018

Issue description

Currently, chroot_replace is forced to be True in Pre-CQ builds. 
http://shortn/_od9CRc1Dqc

Now we have the incremental InitSDK enabled in CQ, PFQ and other builds, I plan to turn it on in Pre-CQs. Will there be any potential blockers for turning off chroot_replace and letting Pre-CQs benefit from incremental InitSDK?






 

Comment 1 by nxia@chromium.org, Jan 30 2018

Blocking: 803693
Turning on incremental InitSDK in the CQ is currently blocked on https://crbug.com/752562.

Assuming we get that resolved, I'm not so sure incremental InitSDK would have the same benefits for pre-CQ.  When the CQ is done, the CLs get submitted and go into the chroot, so we only have to rewind the chroot when the CQ doesn't pass.  Stuff that passes the pre-CQ doesn't directly get submitted, so we ideally wouldn't want it to be present in the next run.  Would the idea be to rewind the chroot every time regardless of the pass status?  

Comment 3 by nxia@chromium.org, Jan 30 2018

if rewinding the chroot takes less time than deleting the old chroot & creating a new chroot, it's still doable.

if a pre-cq submits the CLs it tested directly, it can create a file (say /chroot/submitted_cl_in_pre_cq_flag) locally.
InitSDK stage checks if the flag file exists, if yes, reuse the chroot and remove the flag file, else, rewind the chroot.

Comment 4 by nxia@chromium.org, Feb 1 2018

Per the discussion in yesterday's meeting, the idea of when to preserve chroot in #3 isn't right. As during two pre-cq runs, some CLs which can affect the SDK may be landed to master.

Better solutions per discussion are:

1) A Pre-CQ build should InitSDK without any applied CLs first; in the followed Pre-CQ runs, it should always rewind to the saved chroot and only apply the updates. The pre-cq can create the clean chroot every day (or every 12 hours).

OR 

2) Let a builder (say master-paladin) create a clean chroot and upload the chroot image to GS if it passed and committed all CLs. Pre-CQ can first compare its local chroot image version with the chroot image on the GS, if the image is old, download the chroot image from GS. In the InitSDK stage of the Pre-CQ run, it should always rewind back to the downloaded chroot version, and only apply the chroot updates.
Cc: -davidjames@chromium.org
Status: Assigned (was: Untriaged)
Should this be handed off to the build/CI team?
Components: -Infra>Client>ChromeOS Infra>Client>ChromeOS>CI
Owner: jclinton@chromium.org
yes
Labels: -Type-Bug Type-Feature
Owner: ----
Status: Available (was: Assigned)
Ben, are we clear to turn this on in PreCQ?
Snapshots have been on for about a week and are working well in the CQ and incremental builders.  You could definitely turn them on, but with the current implementation, they wouldn't help much with the Pre-CQ.  I'm working on a proposal to use snapshots in more places; I think that will address the Pre-CQ as well.

Sign in to add a comment