4585955a8b
Every run we are doing a full tar.gz of the chroot environment that never gets used. It's not suitable for CI since we use fresh images each time there. The cache in general isn't really isn't a very safe thing to have around, because there's no invalidation procedure and no real way to make one -- we've no guarantee that a new chroot build even moments after a previous one wouldn't bring in or different packages, etc (of course this is *unlikely*, but the longer you go between builds the worse the problem becomes. Also, tons of packages get installed after this not from any cache, so potential speed-up is rather marginal. Debian turned this off with I58fc485aacacaa17243bf9ce760ed91256d1f182. However, given the reasons above and it's complete lack of testing, I don't see this as useful. If we really want this type of thing, I think we should come up with a way to use a persistent external yum/dnf cache that yum/dnf keeps in sync with it's usual invalidation rules. Change-Id: I66789c35db75c41bc45ea1ad2e26f87456de4e4d |
||
---|---|---|
.. | ||
1.16.0-updates-bad91fc0b36c1755.yaml | ||
1.17.0-ef744f36d277dba4.yaml | ||
1.18.0-4433d3076627f10d.yaml | ||
1.18.1-ceeb514708dcb731.yaml | ||
openssh-server-0f6d065748a2fc18.yaml | ||
opensuse-minimal-45267f5be1112c22.yaml | ||
package-install-arch-38bb5a6e61794fa5.yaml | ||
package-outside-debootstrap-ac93e9ce991819f1.yaml | ||
runtime-ssh-host-keys-7a2fc873cc90d33e.yaml | ||
start-using-reno-446b3d52a467a273.yaml | ||
yum-cache-removal-148c33012515e56e.yaml |