[BUG] cannot customize oci:// app compose.yaml as variable interpolation fails

[thediveo]

Description

When me or my users want to deploy a compose application using an oci:// URL without or with customization, docker compose fails to interpolate the variables in the fetched oci:// artifact.

The OCI artefact application was published as follows https://github.com/thediveo/lxkns/blob/9a75011550bc03c6610ae6618be1c2b72f3fe2aa/.github/workflows/buildandrelease.yaml#L87:

      - name: Publish compose file as OCI artifact
        shell: bash
        run: |
          echo "${{ steps.metadata.outputs.tag-names }}" | while read -r tag; do
            TAG="$tag" docker compose \
              -f deployments/oci-artifact-app/docker-compose.yaml \
              publish --resolve-image-digests \
                ghcr.io/${{ github.repository }}/app:$tag
          done

The published compose.yaml looks as follows in what gets pulled; the $TAG gets overridden by the image sha pinning:

name: lxkns
services:
    lxkns:
        image: ghcr.io/thediveo/lxkns:${TAG:-latest} # gets sha256-pinned as part of publication
        restart: 'unless-stopped'
        read_only: true
        command:
            - "/lxkns"
            - "--debug"
        ports:
            - name: "lxkns web UI and API"
              host_ip: "${LXKNS_ADDRESS:-127.0.0.1}"
              published: "${LXKNS_PORT:-5010}"
---
services:
  lxkns:
    image: ghcr.io/thediveo/lxkns:latest@sha256:85582c982042c534ec6d07805795907c9cb17b54e72803c8f77d963d0aeae240
h

From reading other issues for this repo I got the impression that it is perfectly intended for OCI artifact app publishers to allow their customers/consumers to customize the deployment.

While the pulled and locally stored compose.yaml can be perfectly well deployed using docker compose -f ~/.cache/... up, doing so using docker compose -f oci://... up fails.

I'm confused: did a made a stupid mistake I'm overlooking all the time, wasn't this ever intended to be used as such ("you're holding it wrong") or is this a composer plugin bug?

I tried with --with-env but it didn't help; additionally, it never stopped to ask for confirmation. How exactly is "docker compose publish" in combination with variable interpolation supposed to work when there are defaults set in the compose file itself and no env vars passed to compose publish? The documentation seems to need some love?

Steps To Reproduce

1. a Linux host
2. with Docker engine and Docker compose, where Docker compose is, say v2.40.3 or v5.0.2.
3. docker compose -f oci://ghcr.io/thediveo/lxkns/app:0.42.8 up
   results in:

   services.lxkns.ports.[]: invalid ip address: ${LXKNS_ADDRESS:-127.0.0.1}
   

Compose Version

Docker Compose version v5.0.2

Docker Environment

Client: Docker Engine - Community
 Version:    29.2.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.31.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 10
  Running: 9
  Paused: 0
  Stopped: 1
 Images: 40
 Server Version: 29.2.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.17.0-14-generic
 Operating System: Ubuntu 24.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 15.62GiB
 Name: ***
 ID: ***
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: thediveo
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Anything else?

Look! A SQUIRREL!!!