We have the script "cros clean" which is intended for developers, but which does MOST of what we want.

I suspect that extending it is the right thing to do, however, I'm not sure if we have a policy around using (or not using) "cros" commands on builders. There are a few examples where we do that today.

This will (as far as I understand it) be handled by the OverlayFS Lann setup. "Cleanup" turns into un-mounting the RW layer.

We also need to squash overlay changes into the RO layer here if the build succeeded. This is a performance optimization that's saving us about 20 minutes per build.

That's currently handled by LVM snapshot merging which, IIRC, is more performant than overlayfs squashing because the squash operations are done on a per-file basis instead of on a per-block basis in LVM.

Correct me if I'm wrong, but I think those are different volumes. This is the build root (which get's tons of junk dumped to it during a build that we don't want sticking around for the next build). It's irrespective of performance optimizations. Aka you would never want to 'squash' this into an RO.

Yes, we currently squash the build root because Portage gracefully handles removing transient build artifacts such that we are only left with the package install graph that speeds up the N+1 build.

"Portage gracefully handles" I'm getting that framed and put on your desk.

Many things that I don't like about Portage but this isn't one of them; it does do this part very well.