integration: disable gc

[tonistiigi]

closes #857

This looks like the most likely reason for #857 flakiness

Signed-off-by: Tonis Tiigi [email protected]

[AkihiroSuda]

Can we consider increasing gc-keepstorage instead? It seems important to test daemon with GC enabled.

[tonistiigi]

What's the difference between big keepstorage and gc=false? Note that there is no tests that actually test gc because of its unpredictability. All tests that check if refs properly become releasable are still running with this.

[ijc]

If integration tests can fail due to the gc is there an implication that actual user workloads might fail too?

I'm 99% sure that answer is "no", because the tests are doing extra sanity checks around lifecycles etc post Solve and it is those which the gc is interfering with in a non-deterministic way -- but I thought it worth confirming.

[tonistiigi]

The specific test that fails checks for cache mounts persistence that is not a guaranteed behavior. Normal builds should work with any cache state but the test expects a specific state as the prune is not supposed to run in between solve requests.

I'm not 100% sure what exactly causes the gc pressure though. I'll see if I can reproduce locally and understand that.

[tonistiigi]

My current guess is that it is not that cache mounts actually get deleted by the gc, but that if gc happens to run in this specific moment it takes a reference for the size calculation and because size calculation already holds a reference a new fresh cache mount would be used for the build.

Quite annoying but don't have a good idea for a different simple fix atm. Probably this would need to be a special internal exception for mutable refs.

[tonistiigi]

Source issue tracked in #883