Tag docker images without using the date to allow for automation
Exadra37 opened this issue · 4 comments
Thanks for this awesome project :)
I am trying to use the hexpm images to automate an Elixir Docker Stack but in my analysis of available tags it looks like that only the Alpine ones will be suitable to use in an automated way because they don't have a date on them.
This works:
$ docker pull hexpm/elixir:1.12.3-erlang-24.1.2-alpine-3.14.2
1.12.3-erlang-24.1.2-alpine-3.14.2: Pulling from hexpm/elixir
a0d0a0d46f8b: Already exists
74e66af6dba9: Pull complete
078c0fc5e943: Pull complete
656529acb1e6: Pull complete
Digest: sha256:21f80e0ef4fea14624df49e0904bdeb65448ef50ba4da9ae7d0c1a9cb393da83
Status: Downloaded newer image for hexpm/elixir:1.12.3-erlang-24.1.2-alpine-3.14.2
docker.io/hexpm/elixir:1.12.3-erlang-24.1.2-alpine-3.14.2It fails for Debian default image without a date on the tag:
$ docker pull hexpm/elixir:1.12.0-erlang-24.1.2-debian-buster
Error response from daemon: manifest for hexpm/elixir:1.12.0-erlang-24.1.2-debian-buster not found: manifest unknown: manifest unknownSame goes for Debian slim images:
$ docker pull hexpm/elixir:1.12.0-erlang-24.1.2-debian-buster-slim
Error response from daemon: manifest for hexpm/elixir:1.12.0-erlang-24.1.2-debian-buster-slim not found: manifest unknown: manifest unknownWould it be possible to release tags for Ubuntu and Debian without using the date on them?
For example, a docker pull for hexpm/elixir:1.12.0-erlang-24.1.2-debian-buster-20210902-slim would be also possible with docker pull hexpm/elixir:1.12.0-erlang-24.1.2-debian-buster-slim.
What kind of automation are you doing? Why does the date in the tag stop you from automating things?
What kind of automation are you doing?
I am using a bash script to generate on the fly an Elixir stack for development based on a configuration file that contain the exact versions used by the app.
Why does the date in the tag stop you from automating things?
The issue with the date is that I need to know it in advance and hardcode them in my bash script code while if I could retrieve the images like its done with Alpine then the automation would be straightforward :)
The Alpine and Debian tag naming work the same way. It's just that that the Debian source images we use include a date in the version string and the Alpine use a more traditional x.y.z version. Where Alpine use 3.14.2 as version Debian uses buster-20211010, but in practice there is no difference.
The images are never updated, the reasoning being that you should always get the same image without any potentially breaking changes from an updated image.
I am not sure what the issue is, the same way you hardcode alpine-3.14.2 you can hardcode debian-buster-20211010?
Where Alpine use 3.14.2 as version Debian uses buster-20211010, but in practice there is no difference.
Debian also provides the docker image with a tag that doesn't reference a date, but I see now the reason why you prefer the ones with date:
The images are never updated, the reasoning being that you should always get the same image without any potentially breaking changes from an updated image.
I am not sure what the issue is, the same way you hardcode alpine-3.14.2 you can hardcode debian-buster-20211010?
The automation I wrote some years ago (before hexpm) builds from source, Erlang solutions and docker hub official images and I was now adding hexpm support to it, and coincidentally your tagging convention is very similar to the one I use, except for the date on the tag. The date on the tag breaks all the automation I have already in place if I want to add hexpm support.
Thanks for taking the time to reply to my request and I perfectly understand if you can't add support for the debian tags without a date.