[Feature Request] docker compose tag --template "template" --push

[abdennour]

Description

I would like to tag my built images, then, optionally, push these tags.
In CI environment, image tags are auto-calculated, and CI has to do some governance regardless the YAML definition of .services{}.image

Poposal
Adding subcommand docker compose tag with the following options:

• --template string: the tag template which can leverage the following variables :
  - {{ .ServiceName }} - service name under tagging
  - {{ .ProjectName }} - compose project name
  - {{ .ServicesCount }} - Total number of services
  - {{ .ServicesToBuildCount }} - Total number of services to build
• --push: whether to push the new tag(s) or just tagging

i.e.

docker compose tag --template "myregistry.local/myrepo/{{ .ServiceName }}:v1" --push 

Scenario 1

Given a docker-compose file as following:

version: "3.9"
services:
  frontend:
    build: frontend/
    ports:
     -  9090:80
  backend:
    build: backend/
    ports:
     - 8080:80
    image: mybackend:v1
  db:
    image: mysql

And given this script (After implementing this feature)

VERSION=v1.2.3
APP=myapp
docker compose tag --template "nexus.local/myrepo/{{ if eq .ServicesToBuildCount 1}}$APP{{ else }}$APP-{{ .ServiceName }}{{ end }}:$VERSION" --push

Results:

• New image tag with name nexus.local/myrepo/myapp-frontend:v1.2.3 is created & pushed
• New image tag with name nexus.local/myrepo/myapp-backend:v1.2.3 is created & pushed

[abarrak]

Would maintainers kindly take note of this good feature?
it maximizes productivity and bundles compose with alternative option to tag and push.

[abdennour]

I think @glours or/and @ndeloof could help here

[ndeloof]

Could you please clarify the uses cases for - {{ .ServicesCount }} / {{ .ServicesToBuildCount }}
service definition in compose.yaml should not be considered ordered imho and while service name sounds relevant to me to tag images, I hardly understand the usage of such counters.

[abdennour]

The use case is CI system has to push built images.
CI system has to apply GRC on image naming. Thus, CI system has to re-tag images as per organization naming conventions, then push them to the registry.

[ndeloof]

I understand the global feature request to have additional/atlernative tags for image built by compose, I just wonder about the ServicesCount / ServicesToBuildCount variable you suggest. I don't feel the need for those, and they suggest a fragile design for deterministic image tags

[abdennour]

Oh! I see your point @ndeloof.
Actually this is the usecase of "ServicesToBuildCount" :

• While applying the auto-tagging by the CI system, we may reuse the COMPOSE_PROJECT_NAME as name of the repository ( my.registry/${COMPOSE_PROJECT_NAME}:${VERSION} )
  i.e. COMPOSE_PROJECT_NAME=myapp-frontend , then tag is my.registry/myapp-frontend:${VERSION}
• However, what to do if we have more than one service to build ? we may use my.registry/{{ .ServiceName }}:${VERSION} but this can lead to a conflict of naming among many docker-compose.yaml coming from many projects/many git repos.
  Thus, we want to know how many services need to be built & accordingly, we will decide the tag template.

More real example:

VERSION=v1.2.3
APP=myapp
docker compose tag --template "nexus.local/myrepo/{{ if eq .ServicesToBuildCount 1}}$APP{{ else }}$APP-{{ .ServiceName }}{{ end }}:$VERSION" --push

[ndeloof]

I don't expect users would use my.registry/${COMPOSE_PROJECT_NAME}:${VERSION} as this would be terribly ambiguous regarding what has been built. So I expect some variation around my.registry/${PROJECT}:${SERVICE}:${VERSION}. Switching between those would be even worse imho, bringing confusion and eventually more issues reported to project maintainers, i.e. to me ;) So, I'll be more conservative if we approve this feature to make it somehow more deterministic, whatever the compose build command gets as parameters and number of service images to be built.

From my own experience, users relying on compose for CI do tag images with my.registry/${PROJECT}:${SERVICE}:${GIT_SHA} to make it easy track which image has been built from a commit and run tests/deployments accordingly.

[abdennour]

@ndeloof let me know please what's your acceptance criteria ?

[abdennour]

OK guys! WE released this feature from our fork. Feel free to use with caution as it's not the official compose.

Read more also the use case

[ndeloof]

I'm not fully convinced by this approach.
But I'm sure "compose push" is missing a significant part of the pipeline.
I enjoyed the concept of docker/app to "push a compose file and all required images as an OCI manifest" using manifest-list capability to refer to other images. Maybe we could resurect the idea, so that compose push also push the compose file and images under specified tag.

[abdennour]

Any change in the mind ? any news t get this reviewed & merged ?

[abdennour]

@ndeloof Could you please check again? I am pretty sure you may be convinced now

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.