Docker images are pushed on every commit, but do not contain the changes from the corresponding commit

[haines]

Docker images are pushed on every commit to master, but contain the nightly release, not the code from the commit that triggered the build.

This leads to the confusing situation where there are Docker tags for each commit on master (e.g. lycheeverse/lychee:sha-102ecb4) which do not contain the changes in that commit. The only thing that (potentially) changes is the Dockerfile used to build the image.

Also the latest and master tags are identical, which seems redundant, and there is no way to track the latest stable release (#1981).

I would propose that the "floating" Docker tags should be

• latest: the latest stable release
• nightly: the latest nightly release
• master: the latest commit on master

as well as immutable tags

• X.Y.Z for stable releases
• sha-01234abc for commits to master

(plus the -alpine counterparts).

[katrinafyi]

My quick 2c is that yeah, there should be a tag for latest stable, but I think that having docker images for every commit is probably overkill.

At most, the nightly images are 23 hours behind latest master. "Fixing" the per-commit docker images would need a big change to the Docker file and, if you want to keep the current release images too, it would then have two code paths.

To make the image tags make sense, I'd stop the sha-XX tags, I'd change the docker publishing to work on the same schedule as nightly releases, and I'd maybe add nightly-XX tags so you can refer to particular nightly builds.

But it's just my thoughts. I'm not very involved with the docker infrastructure, and I know there's been a bit of work and discussions around it recently. I haven't kept a close eye on it, so maybe other ways would be better.

[thomas-zahner]

Docker images are pushed on every commit to master, but contain the nightly release, not the code from the commit that triggered the build.

I agree that this is unexpected and makes not a lot of sense. It also has to do with reproducibility. This current approach is absolutely non-reproducible. If we rerun the same action associated to a given commit we get a different result each day. A result that has nothing to do with the associated commit but with the current nightly release.

Note that this is the case for Dockerfile-CI.Dockerfile and Dockerfile-CI.alpine.Dockerfile. We also have Dockerfile which does depend on the source files instead of downloading the contents of a URL.

It should be possible to adapt the two affected files to the approach we use in Dockerfile. I'm not quite sure at the moment why such a different and irreproducible approach is used for the other two files. Maybe the initial idea was to speed up build times?

At most, the nightly images are 23 hours behind latest master.

At the moment it seems to be 3 days 😅 didn't investigate this any further.

[katrinafyi]

It should be possible to adapt the two affected files to the approach we use in Dockerfile. I'm not quite sure at the moment why such a different and irreproducible approach is used for the other two files. Maybe the initial idea was to speed up build times?

Oh yeah, I looked right past the non-CI Dockerfile. That could definitely be used more prominently.

It looks like the nightly release was rolled, but now we have to wait for a main commit before the docker images get built and uploaded. It is a bit silly