docker / docker/compose

[Feature] Long syntax for images names

Open
#13,704 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

kind/feature status/0-triage
Dominant language
Go
Stars
38.2k
Forks
5.8k
Avg merge
2d 14h
Merged PRs (30d)
55

Description

Description

I am currently building & running images in CI using this pattern:

  1. compose file:
services:
  my:
    image: myimage:${VERSION}
    build:
      args:
        VERSION: ${VERSION}
      tags:
        - myimage:${VERSION}
        - myimage:latest
  1. .env file:
VERSION=1.0.0

Then I use a (renovate) bot to bump the version number automatically in my CI whenever the upstream package is updated.

Ideally, I would prefer putting the version number in the compose file using an extension & anchor, and then use the version number later in the compose file using aliases. But I can't because I have to "compute" the full image name from the version anchor, and I can't find a way to do that.

In fact, I would like to do something like this:

x-version: &version 1.0.0

services:
  my:
    image:
      name: myimage
      tag: *version
    build:
      args:
        VERSION: *version
      tags:
        - name: myimage
          tag: *version
        - name: myimage
          tag: latest

Note 1: not sure about if the attribute name is named appropriately, maybe use repository or something else?
Note 2: in fact the same problem occur for all the other "composite" fields that don't have long syntax

The end purpose is to have a self-contained compose file that can be easily updated by my "dependency update" bot.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue mentions only the Compose file and .env file; it names no implementation files or tests. Start by reviewing how Compose currently parses image and build fields, then compare existing composite-field syntax with the proposed anchor and alias form. Done means the long syntax and its behavior are specified, implemented, and covered by tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker-compose
Domain
devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.