Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add automatic detection of docker-compose files for trigger #553

Open
Mascherino opened this issue Jan 10, 2025 · 1 comment
Open

Add automatic detection of docker-compose files for trigger #553

Mascherino opened this issue Jan 10, 2025 · 1 comment

Comments

@Mascherino
Copy link

I currently have 70+ containers running and I really don't want to create a seperate docker-compose trigger for each of them.
A way to have WUD automatically detect the docker-compose file for a container based on the container labels would be really nice to have.

My folder structure currently looks something like this:

docker
├── authelia
│   ├── config
│   ├── docker-compose.yml
│   └── secrets
├── backrest
│   ├── cache
│   ├── config
│   ├── data
│   └── docker-compose.yml
├── beszel
│   ├── beszel_data
│   └── docker-compose.yml
└── it-tools
    └── docker-compose.yml
...

Since every container created with docker compose up should have the com.docker.compose.project label which contains the folder name (in lowercase) where the docker-compose.yml is located, you could mount the folder containing all your subfolders (docker in my case), and tell WUD to lookup the docker-compose files by itself.

When the docker-compose trigger is executed, WUD looks up the compose file location with the container label, and checks if a corresponding folder exists in the mounted folder. If it exists, the docker-compose.yml inside is checked if it actually contains the image from the container (just to make sure there are no false positives and the wrong file gets updated), and is then updated with the already existing methods.

@shadofall
Copy link

shadofall commented Jan 12, 2025

I like the idea. but it would also need to re-work the docker compose triggers

currently you need
WUD_TRIGGER_DOCKERCOMPOSE_{trigger_name}_FILE

then if you want manual or any other options you need

WUD_TRIGGER_DOCKERCOMPOSE_{trigger_name}_AUTO

since afaik you would need an AUTO=false for each trigger name to if you wanted to manually kick of the trigger. and i guess one for each container in the compose file? i definatly dont want my postgres to update accidently if i messed up the reg somehow in the future (i havent played with it since I'm not a fan of auto updates and been waiting for the manual trigger process and i haven't had time yet since it's been released)

and one for each other option you might want to use.

So feels like some sort automatic trigger name generation for compose types, would be needed to associate the various trigger options with for the container.

sometimes I think the trigger system would benefit from a config interface. Create Trigger select type. select function. assign containers. and allow one of each type to be set as default as well. but easier said than done and I digress :P

but short term maybe you can use docker ps --format '{{.Names}}' to generate a list that you could for loop through to create a complete list of triggers. at the very least should make the work easier

this should work aside from formatting

for e in $(docker ps --format '{{.Names}}')
do
echo "WUD_TRIGGER_DOCKERCOMPOSE_${e}_FILE=/${e}/docker-compose.yml" >> list.txt
# echo some other trigger here if you need more than one and so on >> list.txt
done

of course I could be completely overthinking it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants