Request for allowing separate definition of image `tag` under `services`

[oalagtash]

Description

It would immensely helpful if I can define the tag of an image separately. This allows the use of YAML anchors and aliases in the compose.yml. Especially if the docker compose gets big and many images have the same tag name (special release).

For example: The following is currently not possible:

version: "3.9"

x-image-tag: &image-tag 2.0.0

services:
    my-image-a:
        image: my-image-a:*image-tag
    my-image-b:
        image: my-image-b:*image-tag

But it would be possible if:

version: "3.9"

x-image-tag: &image-tag 2.0.0

services:
    my-image-a:
        image: my-image-a
        tag:*image-tag
    my-image-b:
        image: my-image-b
        tag:*image-tag

Many Thanks!

[ndeloof]

The common approach to this issue is to define tag by a variable, maybe using a default value or with .env file to declare a reasonable default value:

services:
    my-image-a:
        image: my-image-a:${TAG:-dev}

[oalagtash]

Thanks for your response! I am aware of this approach. This only works if we have a .env file committed in git repo or an env variable maintained on each team member machine. Both ways are not practical, in my opinion. Having this feature would allow defining image tag as YAML alias und use YAML anchor to reference it.

[ndeloof]

Both ways are not practical, in my opinion.

that's the compose way ¯_(ツ)_/¯

[oalagtash]

Not a helpful response ^^

Assume you have 20 images sharing the same tag. And you have .env file locally with 20 lines of configured env variables. This .env you cannot push because it is developer specific. How would you handle a change of image tag? Wouldn't it be great if you have it defined at one place? Specifically in the compose.yml where the service is defined (like showed above)?

[ndeloof]

that's why compose file variables support default value syntax ${VAR:-default} so you don't need a value defined in your .env file to get a reasonable default being set (would typically be set to latest tag on current git branch, or such thing) and a developer still can override value

[oalagtash]

Yes I meant with Interpolation considered. You have ${VAR:-2.1.0} defined 20 times in compose.yml. Each time tag changes you will need to update the 20 places of ${VAR:-2.1.0} to ${VAR:-2.2.1}, while making sure not mistakenly changing unrelated image that might hold the same tag. In such cases, it is failure prune.

If tag: was to separate from image:, we could have one YAML alias x-image-tag: &image-tag 2.1.0. Changing this alias will only effect services referencing it.

[oalagtash]

Maybe even like this (did not test it but should work): x-image-tag: &image-tag ${VAR:-2.1.0}. This way we preserve the "compose way" :)