To be more specific, if the build emerges host targetted ebuilds in the chroot, I'm not sure if those changes get cleaned up before the next build.

Looking at the relevant code, I don't think these changes would be cleaned up.

https://cs.corp.google.com/chromeos_public/chromite/cbuildbot/stages/build_stages.py?rcl=a03df19ec00b366b4aee6d86ca1a51926707fc41&l=34


This is only a single build config which doesn't build very frequently. Perhaps that build config should simply destroy the chroot after it's done. I believe that would leverage bmgordon@'s work to reduce the cost of recreating the chroot next build.

i don't know what "host targetted ebuilds" refers to

in the past, we had cases that would trigger nuking the chroot so we'd start over with a pristine version.  failed runs that involved updating the chroot for example.

but if rolling back to a previous snapshot is cheap now, we should just deploy that everywhere.

ayatane's planning to emerge assorted Go based ebuilds into the chroot without using a board. The point is to use our chroot environment/toolchains to generate binaries that will be deployed to servers in the lab.

If it's a single config, it seems like that config could use snapshots itself to revert its own work.  Like #2 suggests, it could also leave the chroot in an invalid state so that the next run cleans it up (and hopefully uses a snapshot to make that cheap).

I've forgotten... when are the snapshots taken? After a successful build?

i'm not terribly worried about stale packages being left installed in the sdk (i don't really see it being a problem), but if the snapshot logic makes it a non-issue, then there's that.