Why does Docker have builds and not GitHub tags are pushed?

[williamdes]

@thomascube I noticed no new git tags are pushed but that the image gets updated.
What is the new process?

[thomascube]

The github actions are not set up to create tags. Previously, tagging (and thus releasing) was a manual process which triggered builds on Docker Hub. Because of the new automation with Github actions, tags are no longer needed. That saying, suggestions how to extend our actions to create tags again are welcome.

[williamdes]

That saying, suggestions how to extend our actions to create tags again are welcome.

Okay, thanks
I think having tags is good to know from what was thrown the workflow

[thomascube]

We could consider to create tags for each version again but some questions come to my mind:

• How to build new images if we make changes to the Dockerfile but the Roundcube version is unchanged?
  • Moving the Git tag?
  • Different versioning schema for Docker images?
• Same question for periodic updates of the base image (php) without Roundcube version changes.
• How to do auto-update as we currently do with the update.sh cron job?
  • Can github actions create tags?

[williamdes]

We could consider to create tags for each version again but some questions come to my mind:

* How to build new images if we make changes to the Dockerfile but the Roundcube version is unchanged?

Trigger the same tag once more ?

  * Moving the Git tag?

This one is for me a bad option, avoid moving git tags.

  * Different versioning schema for Docker images?

* Same question for periodic updates of the base image (php) without Roundcube version changes.

* How to do auto-update as we currently do with the update.sh cron job?
  
  * Can github actions create tags?

Using git tags is quite easy and will do the trick
You can automate all this
Look at how I derived GitHub caching to do this here: https://github.com/sudo-bot/docker-phpmyadmin-snapshots/blob/main/.github/workflows/cron.yml

And when a release is published, then it is built: https://github.com/sudo-bot/docker-phpmyadmin-snapshots/blob/main/.github/workflows/publish.yml#L8

[pabzm]

I don't quite understand this issue. Roundcubemail uses git-tags only for releases, if I am not mistaken. And these releases are picked up by update.sh. And the images are tagged with the version numbers, too.

Can someone explain what's missing?

[williamdes]

Can someone explain what's missing?

For example this update has no git tag, it should have one.
Ref: 3deedba
Ref: https://github.com/roundcube/roundcubemail-docker/tags

Each new released version send to the Docker hub should have a tag, and I noticed that there is no more

[pabzm]

@williamdes I'm still a little confused, sorry. Do you speak about git-tags in the commit-log of this repository, or container-tags on the built images? Or maybe container-labels on the images?

Because the container-images do all have tags: https://hub.docker.com/r/roundcube/roundcubemail/tags

I also don't understand your previous comments. How is "Trigger the same tag once more" different from moving a git-tag to a different commit?

And the links you posted in that comment create tagged releases – but we don't do releases in this repository?

[pabzm]

To make it more concrete:

For example this update has no git tag, it should have one.

Which git-tag do you think that commit should have?

Each new released version send to the Docker hub should have a tag, and I noticed that there is no more

What do you mean by "released version"? A release from roundcube/roundcubemail?

Which tag do you think the latest built container image should have?

[thomascube]

This is how I understand this discussion. It raises two questions

• what shall tags in the Docker repo represent? Roundcube release versions or Docker build versions?
• and second, how do these tags in the Docker repository correlate with tags (or other identifiers) in this Git repository?

Both not easy to answer because very much a matter of taste and philosophy.

So far the tags we published in the Docker repo represent the Roundcube release versions. They can be replaced/updated with new builds from this repository that inherit either changes in the base images or in the Dockerfiles. This way consumers can subscribe to a Roundcube release and still get the latest updates from the PHP base images.

This pattern is hard to map 1:1 with Git tags and we did a bad job regarding this in the past. Changes to the Dockerfiles can be applied to tags by constantly shifting tags to new commits but some may consider this bad practice. Tags in Docker and tags in Git may not necessarily have the same meaning. Changes to the base images cannot be tracked in Git unless we store the sha sum of the base images in the Dockerfiles (-> update with renovate). With #281 the exact contents of a Docker image cannot be represented in Git anyway.

So let's first try to agree to an answer for question one. Maybe it's time to re-think or extend the Docker tagging strategy.
And then we can think about ways how to link image references in the Docker repo to tags, branches or commits in this Git repo.

[pabzm]

I think the image-tags should definitely reference the Roundcubemail version. But maybe we can additionally include more details, by using container labels, or additional tags.

But to discuss that I still would like to know an actual use case for those details. Because without one we don't have any criteria (besides personal preference) for a decision, I think.

[pabzm]

@williamdes Would it help in your opinion if we pushed each built image additionally tagged with the shortened git commit ID of this repo (not the roundcubemail repo)?

[williamdes]

@williamdes Would it help in your opinion if we pushed each built image additionally tagged with the shortened git commit ID of this repo (not the roundcubemail repo)?

I think this is what I asked in my messages
Basically:

• git checkout
• build image
• push image
• git tag
• git push tag

So you have a tag in git for each pushed Docker image
Is that what you also understood ?

[pabzm]

Basically yes, but I suggested to use the git commit ID. Why would you prefer tags, and what would you name those tags?

[williamdes]

Basically yes, but I suggested to use the git commit ID. Why would you prefer tags, and what would you name those tags?

I think you mean to change the Docker hub tag, this is not what I want

But in case you think about the git tags here, then the answer is:
for example 123da95 would be 1.6.10-1
if the image needs to be re-built or pushed once more, then use 1.6.10-2 and so on

"I suggested to use the git commit ID" maybe there is a misunderstanding from one of us on this part 🤔

[pabzm]

I meant not to change the docker tag but to add one tag to each image.

E.g.:

docker.io/roundcube/roundcubemail:latest would also get the tag (and be available as) docker.io/roundcube/roundcubemail:a62e4b6f (because it was built from git commit a62e4b6).

for example 123da95 would be 1.6.10-1

But we're building also nightly from this repository and that commit. And in general the code in this repo isn't really tied to the version numbers of roundcubemail. To me it feels wrong to add Roundcubemail version numbers to this repo.

Could you maybe explain why you want to tie them together? That could maybe help me to understand and us to find another way to do things?