Skip to content

Conversation

@idelvall
Copy link
Member

No description provided.

@ijc
Copy link

ijc commented Aug 16, 2024

I think this closes 90% of the hole, but I think one remains where within a branch the code is reverted to an older (layer cached) version, at which point the wrong target cache content could be used still.

e.g.

  1. A build runs at commit C1, layer cache for COPY contains C1 @ time T1, target cache contains build of C1 with timestamp T2
  2. A build runs at commit C1+C2, layer cache for COPY now contains both C1 @ time T1 and C2 at time T3, target cache contains build of C2 with timestamp T4
  3. A build runs at C1+C2+revert(C2), layer cache hit on C1 at time T1, cargo compares source T1 with target cache T4 and determines that it can use the cached build of C2 when it should instead have rebuilt C1. (force pushing C1 dropping C2 would have the same effect.

(NB: T4>T3>T2>T1)

I've proposed #63 as a possible alternative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants