docker image should be tagged

kiwix / kiwix-tools

Command line Kiwix tools: kiwix-serve, kiwix-manage, ...

https://download.kiwix.org/release/kiwix-tools/

GNU General Public License v3.0

462 stars 87 forks source link

docker image should be tagged #373

Closed rgaudin closed 3 years ago

rgaudin commented 4 years ago

At the moment, there is no tag (but latest) available on the kiwix/kiwix-serve docker image. Given it's a released software with changing features, it's a problem.

Additionnaly, the Dockerfile uses a version-less download URL

https://github.com/kiwix/kiwix-tools/blob/6ba6046850eb92f6d23408f38a5de93c970720a1/docker/server/Dockerfile#L7

one can not know the version in use from the docker file
this could lead to problems:
- link on that URL might be incorrect at time of build. For example, the current build on the hub was launched an hour before the release arrived at that location
- the builder might have cached the layer with that line resulting in unexpected result.

kelson42 commented 4 years ago

@rgaudin I have created the proper Docker hub hooks https://hub.docker.com/repository/docker/kiwix/kiwix-serve/builds

kelson42 commented 4 years ago

@rgaudin The problem with URL is well known. The only solution I'm aware off, is to compile everything locally. That implies to to track all the dependences (like in kiwix-build)... which is not really maintainable as well. So, i have basically no solution so far to that problem. @mgautierfr Do you have idea how we might rely properly on kiwix-build?

rgaudin commented 4 years ago

I know it's not easy to fix, that's why I opened the issue ;)

I don't think what you did is of much help if you don't link to a versioned link. It might actually be worse as there are good chance that when you push the tag, the build is triggered before the new release is uploaded resulting in a tagged image that have the wrong binary…

The solution for using an external binary is to have the version in the Dockerfile I'm afraid. That means having a dedicated tag for docker docker-v3.10 that triggers the build but then you have to make sure this tag doesn't triggers other things accidentally.

So maybe the solution is to have a separate repo for the Dockerfile. It's not elegant (we have to push on this repo after the release – that might be automated) but it would work. A link to that repo from the readme is seems OK to me.

rgaudin commented 4 years ago

Weighting in on this. As of right-now, there's a 3.1.0-2 version in the release folder but the docker had not been updated since 3.10 release…

I see that this repo (kiwix-tools) has no tag for this sub-release (I suspect it's packaging version only but the same code base?) so the hub did not run.

So just to be clear:

image kiwix:kiwix-serve:latest provides 3.1.0 instead of 3.1.0-2
image kiwix:kiwix-serve:3.1.0 provides 3.1.0 instead of 3.1.0-2

Screen Shot 2020-04-22 at 16 47 24

I am manually triggering a build on the hub now to fix it but the problem will continue on next release. This one is related to -2 version but next release will be similarly impacted by the delay between tarball on release and docker hub build.

kelson42 commented 4 years ago

@mgautierfr At this point we need your oponion here to avoids duplicates. Maybe all of this should be handled in (or in relation) with kiwix-build?

kelson42 commented 3 years ago

With @rgaudin, we have decided to fix the problem by implementing similar approach like https://github.com/openzim/zim-tools/issues/202