exec: fix pruning cache mounts with parent ref on no-cache

[tonistiigi]

fixes #5305

On a build with no-cache, cache mounts were not pruned correctly if the mount was on top of another ref. This also appeared in Dockerfile when mode/uid/gid was set because implicit parent ref is created in these cases in order to change the permissions of a subdir that is used as a cache mount base.

Because it is not possible to know ahead of time what ref will become the parent of cache mount during build, all cache mounts matching the ID that have a parent will be pruned.

[polarathene]

Since this will remove the ability to do a build retaining the cache mounts while only discarding the layer cache, is there currently an advised way to achieve the behaviour that's deemed as a bug?

--no-cache is useful to perform a build without layer cache, but I'm not a fan of that forcing a cache mount that other Dockerfile use too. From now on will the only approach way to preserve the cache mounts be via temporarily changing the id before --no-cache is used? (such as with a build arg?)

I'm aware of the existing tracking issue related to separate control, but that's been unresolved for some time. Just curious if there will still be a viable workaround.

[tonistiigi]

@polarathene --no-cache-filter for pruning cache mounts is tracked in #1213 . Atm. you can use --no-cache-filter with specific stages, or invalidate cache with some other methods like updating ARG. You can also change the namespace for cache mounts if your use case is to do one-off builds that do not affect cache mounts for other invocations https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/reference.md#buildkit-built-in-build-args .

[crazy-max]

should we if idx+2 < len(k) { to handle out of bounds?

[crazy-max]

actually that's fine looking at https://github.com/moby/buildkit/pull/5306/files#diff-ae44b7efd0878d4ad4013864764f0046c5c75f5f7dfe08718ad3bd32cabf9caeR104

[tonistiigi]

That should not be possible. Then the idx would be -1. In the worst case itemID can be ""