New issue
Advanced search Search tips

Issue 834134 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

cros chrome-sdk: Remove old toolchains & tools for previous SDK versions from the cache.

Project Member Reported by bpastene@chromium.org, Apr 18 2018

Issue description

When chromium devs (and bots) start using the chrome-sdk more frequently, their local cros caches are going to fill up with a new set of toolchains and misc tarballs every time the lkgm gets bumped.

We could add the "--clear-sdk-cache" option to all sdk invocations, but that would make the cache totally cold each and everytime, leading to several minutes worth of network fetching. (This is what we're currently doing on bots; it's bit less practical for developers, since we expect any consecutive syncs to be a no-op if no relevant code changes were made.)

It would be ideal if the sdk ensured that the cache contains toolchains for only the current version. This has the benefit that:
- any toolchains for versions we're not currently using get removed
- the toolchains for the current version stick around

Consequently the cache stays reasonably sized, and re-initializing the cache will be a no-op if the lkgm doesn't change. WDYT?

Filing as low-pri since an extra 2-3 minutes in a sync isn't the worst thing in the world.
 
Cc: -achuith@chromium.org
Owner: achuith@chromium.org
Status: Assigned (was: Untriaged)
Something like --delete-old-versions. I can take a look.
Status: WontFix (was: Assigned)
Don't think we care about this as we're downloading a fresh SDK with every build. Ben, please re-open if you'd like me to work on this.
Should we be concerned about the size of the cache for devs? It's a little buried now. My build/cros_cache dir is currently at 16G.

I don't think there is much value in keeping old versions for a particular board. I think that the default behavior should be to delete older versions for a board when fetching a new version.

16GB ?  we don't even count that low :p.

i don't think implementing some expiration policy on entries in the cache would be too big a deal.
Status: Assigned (was: WontFix)
I looked into this and it's not as straightforward as I'd hoped because we first need to load the cache to determine if it's stale, then unload and delete it. It's not quite like --clear-sdk-cache which can blindly delete the cache very early in the proceedings.

I'll re-open the bug, but P3 sounds right.

I use --clear-sdk-cache every time I re-enter the SDK after syncing my repo.

Sign in to add a comment