Support updates to partial docker compose file

[avargaskun]

fixes #586

from: #586 (comment)

I'm running into another instance of this issue. I split my compose project into 'modules' and include each module's partial compose file conditionally at the time docker compose up is called. I create multiple dockercompose triggers, one for each partial compose file that defines a service. The problem is, some of the partial compose files specify overrides for services they depend on, so there are sometimes 'incomplete' service definitions in a given compose yml file.

Example:

base/docker-compose.yml (fragment)

services:
  wud:
    container_name: wud
    image: ghcr.io/getwud/wud:8.0.1
    # ...
    environment:
      - TZ=${TZ}
      - WUD_WATCHER_LOCAL_CRON=0 8 * * *
      - WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false
      - WUD_TRIGGER_DOCKERCOMPOSE_BASE_AUTO=false
      - WUD_TRIGGER_DOCKERCOMPOSE_BASE_FILE=/wud/compose/base/docker-compose.yml
      - WUD_TRIGGER_DOCKERCOMPOSE_BASE_PRUNE=true
    labels:
      # ...
      wud.watch: true
      wud.trigger.include: dockercompose.base
      wud.display.icon: sh-wud
      wud.tag.include: ^\d+\.\d+\.\d+$$
      wud.link.template: https://getwud.github.io/wud/#/changelog/?id=_$${major}$${minor}$${patch}

portainer/docker-compose.yml (fragment)

services:
  wud:
    environment:
      - WUD_TRIGGER_DOCKERCOMPOSE_PORTAINER_AUTO=false
      - WUD_TRIGGER_DOCKERCOMPOSE_PORTAINER_FILE=/wud/compose/portainer/docker-compose.yml
      - WUD_TRIGGER_DOCKERCOMPOSE_PORTAINER_PRUNE=true
  portainer:
    container_name: portainer
    image: portainer/portainer-ce:2.27.4
    # ...
    labels:
      # ...
      wud.watch: true
      wud.trigger.include: dockercompose.portainer
      wud.display.icon: sh-portainer
      wud.tag.include: ^\d+\.\d+\.\d+$$
      wud.link.template: https://github.com/portainer/portainer/releases/tag/$${major}.$${minor}.$${patch}

The problem is that the code for the Dockercompose trigger iterates the services in my partial file for portainer and finds the 'incomplete' definition for wud. Specifically, it tries to access properties of services.wud.image and fails because image is not defined for wud in this particular file.

[HCanber]

This PR also addresses an unrelated issue with splitting a Compose file into multiple files.

The code currently expects the services section to always include an image property. However, this is not necessary if a build property is specified.

For example:

services:
  my_example:
    container_name: my_example
    build:
      context: ./dockerfiles/my_example

"image may be omitted from a Compose file as long as a build section is declared."
https://docs.docker.com/reference/compose-file/services/#image

[thecoshman]

@HCanber how would that work with WUD? If the image is built on demand as part of deploying the compose file... there's no image to watch for updates...

Side note, I moved away from using that as it's fairly trivial to just build images and publish them somewhere.

[Heartnett]

@fmartinou @manfred-martin-lyra @PrivatePuffin PING

[PrivatePuffin]

@Heartnett @fmartinou

Technically this can be merged, though we might want to add a testcase as well.
We can safely assume if an image is not present we can just ignore it and go on, instead of hard-error.

[PrivatePuffin]

@HCanber how would that work with WUD? If the image is built on demand as part of deploying the compose file... there's no image to watch for updates...

You're correct, this comment can be hidden as it adds nothing and doesn't contain a reference that is parseable by WUD

[johntdyer]

hey guys, any chance of this being merged into main and cutting a new release?