Replies: 1 comment
-
Hi, Your error indicate that you give Is Because Example services:
whatsupdocker:
image: getwud/wud
...
volumes:
- /my/host/path/docker-compose.yml:/my/container/path/docker-compose.yml
environment:
- WUD_TRIGGER_DOCKERCOMPOSE_EXAMPLE_FILE=/my/container/path/docker-compose.yml
``` |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I prefer not to have WUD auto-update my containers, as I like to verify for any potential issues with new versions before proceeding with an upgrade. Additionally, I have some compose files with multiple containers that require special attention during updates.
While I appreciate that WUD can identify the latest version and allows me to configure triggers for manual execution, managing the extensive list of environment variables in my compose file becomes challenging after a few containers. In an attempt to streamline this process, I tried setting the path for the compose file as /dockerCompose/$${container.name}/docker-compose.yaml.
I have organized the folders for each compose file to correspond with the container names. I assumed I could use the container.name variable for this path setup, similar to how it is used for SIMPLETITLE or SIMPLEBODY in SMTP triggers. However, when implementing this approach, the trigger does not appear under my triggers. Upon reviewing the logs, I encountered the following warning: WARN whats-up-docker/registry: Some triggers failed to register (Error when registering component dockercompose (ENOENT: no such file or directory, access '/dockerCompose/${container.name}/docker-compose.yaml'))
Is there a correct method to achieve this, or am I stuck with managing a long list of environment variables within my Docker compose files?
Beta Was this translation helpful? Give feedback.
All reactions