How to delete cached build

Product support
1

I have a dockerfile that git clones a repo. The repo has been updated but the git push of the dockerfile just uses the cached version rather than the updated version. Is there any way of forcing the resin.io build to re-clone from the repo?

2

Hey,

That is odd – would it be possible to see the Dockerfile or at least the line in question?

It may be the case that the git clone itself is misbehaving, as we use qemu on the build server in order to provide a beefier ARM build, and qemu has a known issue with running git clone (it’s really weird that’s the case…)

I’ll ask my colleague who has better knowledge on the caching features to take a look, but a few hacky possibilties which might work for the time being are one of:-

  1. Edit this RUN line to include --depth 1 if it’s not already there, this change should force it to definitely re-run. It’s a useful thing to include in any case (if you aren’t already) as it limits the clone to just the tip commit and for an install this is usually all you need.
  2. Rearrange the RUN line to be earlier in the process so it forms a different layer.

These are rather hacky solutions, I’ll take a look and see if we can’t find a better approach!

Best, Lorenzo

3

Ok, so having spoken to my colleague, a better solution is to use an environment variable to track the current commit. Unfortunately it doesn’t seem possible to have automatic tracking of a git repo, or even forcing the Dockerfile to not cache for certain commands (or even generally), so this is a variable you will have to track manually, but it does give you the ability to bust the cache whenever you choose to receive a newer commit.

The general form is as follows:-

ENV COMMIT=a10084a2476479b5f4adc08ce55f1d379b061523
RUN git clone [url] [target dir];
WORKDIR [target dir]
RUN git checkout -q $COMMIT

Note that if you were to add --depth 1 here you would need to ensure COMMIT was always tip otherwise the checkout command will fail since it is only retrieving a depth of 1. This could be used as a rather roundabout means of ensuring that you are always on the tip, or of course you could increase the depth to however many commits before tip you expect to reasonably end up at.

An advantage to using this approach is that you can specify which commit you are working from, and of course given the random nature of the hashes, each update is guaranteed to be different + trigger a cache refresh.

Note that all lines after the ENV will be rerun, so construct your Dockerfile carefully to avoid repeating steps that don’t need to be repeated after the clone.

Best, Lorenzo

4

Thanks for those suggestions. Based on that, using something like this seems to work:

ENV VERSION=1.0.0

just before the clone and then changing the version number as required triggers the required pull so there’s no need to deal with the git hashes. Looks like this is a workable technique for clearing caches whenever desired actually.

Thanks for the help - it’s now working exactly as I wanted.

1 Like