Old containers removal prevents pinning

[XeR]

Hello,

Our project, TFNS/CTFNote, uses Hedgedoc's container.

We recently started pinning containers to specific hashes. This ensure our users always pull a version we tested for every containers.

Unfortunately, it looks like the Hedgedoc containers are removed when a new revision of the same version if published. For example, Hedgedoc version 1.9.4-alpine was 90b3c952f489 Wednesday, but it has been updated with 96d00c87ed92 Friday.

Container 90b3c952f489 is available since it is the most recent, but 96d00c87ed92 is not.

The full history is available here : https://quay.io/repository/hedgedoc/hedgedoc?tab=history

Are there any plans to change the build process to keep old containers available for download ?

[davidmehren]

If I understand correctly, Quay deletes untagged images more or less immediately. I don't see a way to change that.

We could probably figure out a build process which tags all images with an additional date or something, so they stay around. But do we want that? We rebuild the versioned images with new base images, so (security) fixes in the base get shipped out. @SISheogorath

[SISheogorath]

Technically speaking they become inaccessible, not deleted, since on can revert to older digests.

However, I would argue, if you need pinned version, please host a (pull through) mirror. I don't think it's worth to push each image with a timestamp since this will only cause significant increases in stuff Quay has to store, keep in mind we use this for free and should try to do our fair share of not causing too much trouble.

What's the your reason to pin the container digest?

[XeR]

Thanks for the replies.

Technically speaking they become inaccessible, not deleted, since on can revert to older digests.

Ah interesting. I never used quay.io (outside of Hedgedoc) so I was not aware of this.

What's the your reason to pin the container digest?

Pinning the container digest helps us making sure our users are using the exact same containers we had when we tested locally. This helps avoiding situations where a bug is caused because one of the container is slightly different.

On top of that, we've seen open-source contributors sabotaging their work (see node-ipc, colors) and projects getting backdoored (see event-stream and, to a certain extent, proftpd and linux mint).

I would rather have as many dependencies pinned because users won't care if the CPU spikes are caused by first party code or by a dependency we cannot upgrade.

However, I would argue, if you need pinned version, please host a (pull through) mirror.

We'll look into this solution, thanks for the idea.

[ErikMichelson]

It seems there is nothing actionable to do for us now, therefore I'm closing this issue. In case your request is still relevant, feel free to re-open this issue or create a new one.