exec: fix pruning cache mounts with parent ref on no-cache#5306
exec: fix pruning cache mounts with parent ref on no-cache#5306tonistiigi merged 1 commit intomoby:masterfrom
Conversation
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. Signed-off-by: Tonis Tiigi <[email protected]>
|
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?
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. |
|
@polarathene |
| if idx == -1 { | ||
| continue | ||
| } | ||
| itemID := string(k[idx+2:]) |
There was a problem hiding this comment.
should we if idx+2 < len(k) { to handle out of bounds?
There was a problem hiding this comment.
There was a problem hiding this comment.
That should not be possible. Then the idx would be -1. In the worst case itemID can be ""
4 participants
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.