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