I just found and started using docker-cache -- thank you!
We encountered an interesting edge case--I was using hashFiles on the Dockerfiles in our repo for the cache key, but our build script creates a new Dockerfile while it runs. Because the key expression is evaluated at runtime when getInput is called, it was returning a different key at the beginning of execution (loading from the cache) vs the end of execution (saving to the cache). This made it essentially impossible for us to ever have a cache hit.
As a workaround, I added a step to manually hash the files and generate a key beforehand, but I think the "expected" behavior for this tool would be to inherently use the same key for load & save, regardless of whether the conditions used to create the key change.
I just found and started using docker-cache -- thank you!
We encountered an interesting edge case--I was using
hashFiles
on the Dockerfiles in our repo for the cache key, but our build script creates a new Dockerfile while it runs. Because the key expression is evaluated at runtime whengetInput
is called, it was returning a different key at the beginning of execution (loading from the cache) vs the end of execution (saving to the cache). This made it essentially impossible for us to ever have a cache hit.As a workaround, I added a step to manually hash the files and generate a key beforehand, but I think the "expected" behavior for this tool would be to inherently use the same key for load & save, regardless of whether the conditions used to create the key change.
Code Examples
If the subsequent steps create a new Dockerfile, the
Post Cache Docker Images
step will generate a new key and save the file to a new cache entry.The workaround:
Here, the key is generated once and used in both the initial and post steps.