Add a button to invalidate the cached Docker image

[cjdb]

Context

I occasionally rebuild compiler images and push them to DockerHub, and it'd be great to have an invalidate button so that one can conveniently update the CirrusCI-prebuilt image.

I need to make small changes like adding or removing a comment to trigger the rebuild at present, so the button would be considered very useful.

[fkorotkov]

Yeah, this should be a part of #379. In the meantime you can add something like

ENV VERSION 16122019

to your Dockerfile to invalidate the image since Cirrus takes MD5 of the content as a key for caching

[cjdb]

Ooft, I didn't realise this is a duplicate issue. Should it be closed?

[fkorotkov]

Let's keep it separate to not forget about the Docker image. 🙌

[real-or-random]

For a rather simple solution, one of these three options will already cover a lot of use cases:

• have a setting in the .yml file that makes the cache only valid for a single CI run (i.e., caching is just used to ensure that all tasks within the same can reuse the image)
• add the possibility to add a fingerprint_script for the Dockerfile
• or simply a way to set the cache expiration time in the .yml file

Is it possible to implement one of those?

Related:
#273
#692

[fkorotkov]

@real-or-random what is your use case? Can you use cache instructions? Building a Docker image for each build might be a bit time costly.

[real-or-random]

I could use cache instructions but I doubt it'll be easier or more efficient.

We have around 30 tasks Linux test tasks testing our C code with different compilers and config settings etc. (Maybe this number will go down a little bit but not a lot.) My idea is to rely on a "bleeding-edge" distro to always get the newest build tools in order to notice if our tests breaks with new compiler versions or other changes in the environment, e.g., due to compiler bugs or ways how the compiler interacts with our code. (It's not clear yet if this will be annoying because we may run into many "boring" failures. I guess we'll need to see.)

Here, docker is simply used to install packages in the distro, e.g., the aforementioned compilers. I still think that's a good idea then. The docker task runs in about 30 s. Maybe without docker, installing the packages will be only 20 s but then we still save roughly 30 * 20 s = 10 min in the build. So it makes sense to build an image for each build.

Of course, an option to expire the cache once per day or something like this would be equally fine. And I believe this should be there anyway. I think a lot of people will want to rebuild their images from time to time to keep with updates and patches of other packages, even if this is done only every 3 or 6 months. So adding a expiry time or (even more flexible) a fingerprint script will be very helpful and should be easy to do.

(See the linked PR for details.)

[fkorotkov]

I see. Looks pretty bleeding edge. 😅

But maybe it will be hard to troubleshoot what caused failure in that case. Was it the environment or was it the code issue. I saw people having a separate repository that defines docker images which are rebuild with a cron. That way you can rebuild once a day and have date as a tag as well as latest always point to the latest date available. That way you'll be able to roll back and check if with the previous environment everything worked. This way there is also a high chance that images will be already precached on Cirrus side so scheduling will be faster.

[real-or-random]

But maybe it will be hard to troubleshoot what caused failure in that case. Was it the environment or was it the code issue. I saw people having a separate repository that defines docker images which are rebuild with a cron. That way you can rebuild once a day and have date as a tag as well as latest always point to the latest date available. That way you'll be able to roll back and check if with the previous environment everything worked. This way there is also a high chance that images will be already precached on Cirrus side so scheduling will be faster.

Indeed, that's sounds like nice setup but I fear it's overkill for our purposes. I'm using NixOs as a distro, which has a rolling release channel. If that breaks, rolling back hopefully won't be too hard because NixOs supports pinning of specific commits of the package repository. I think we'll really need to see if all of this is a good idea. :D

[ckreibich]

Just a bump here, since the Docker build invalidations are not part of #379, right? Would be great to be able to do this without extra commits.

[real-or-random]

Just a bump here, since the Docker build invalidations are not part of #379, right?

My experiments confirm this. But it seems that you can simply trigger a build by clicking "Re-Run" on a Dockerfile task. See for example https://cirrus-ci.com/task/6185661871423488. This is the task skipped due to caching (0:00) but it has the re-run https://cirrus-ci.com/task/5090699217993728, which was actually executed. (Ignore the red task; I had clicked abort there.)

We may need this for bitcoin-core/secp256k1#1313, though a cache expiry option that could be set to a time, e.g., a day or a week, still seems better. I wonder if we could emulate this with env variables after cirruslabs/cirrus-cli#464, but I don't see how to get the current date in an env variable. Maybe one could be provided? ;)