primeval_god

No such integration is planned. Adding git integration encourages pulling complex stacks made and maintained by external projects. The purpose of this plugin is managing simple stacks created via the plugin web interface.

Yes the compose file or any additional files that it includes or references.

Maybe something wrong with a build statement in the compose file or the dockerfile it references? This seems likely to be an issue with the stack rather than the compose plugin. This thread is for plugin support not support for stacks in general.

I wont have a chance to review it until after the holiday weekend at the earliest.

Yes the file wont be editable in the gui but the stack should still start and stop correctly.

Part of your issue appears to be that you are putting foreign files in the compose manager project directory. That directory should only contain files created by the plugin itself. If you are using the plugin with a pre-existing compose stack, it should be saved elsewhere on your system and "Indirect" option used to point the plugin to its location.

At this time it only supports a single env file. I dont remember off hand if the path is to the folder that contains the .env or if it expects a path directly to the .env file. Try both.

Already exists. For each stack, click the "Edit Stack" button and then the "Settings" button and you should see an option to specify the path to the env file. You can point all your stacks at the same file. (not sure if that option is available during stack creation under the advanced dropdown, but it probably should be).

Its been a while since I thought about this issue, so please forgive me if my memory is a bit off. If i remember correctly the absence of a specified icon means the container gets a copy of the default question marked icon cached. I think you have to go in and remove the cached icon to force it to actually pull a new icon. Edit i did not remember correctly.

I would guess because v7.1.0 is nearing release (v7.1.0-rc4 last i heard). I believe Limetech only supports the most recent 2 minor versions i.e. v7.1.x will be current, v7.0.x will be security patch only and <= v6.12.x will be EOL. I would not be surprised to find that some plugin maintainers, particularly for plugins that integrate deeply with unRAID, will follow Limetech's lead on this.

"Extra Parameters" is dockerman terminology for the box that allows you to specify command line flags to be added to the docker run command (typically for options that dockerman does not natively support). Generally speaking you would have to lookup the specific option you are trying to use in the compose file reference. In this case i think the -u option is equivalent to to adding the "user" element to containers in your compose file. https://docs.docker.com/reference/cli/docker/container/run/ https://docs.docker.com/reference/compose-file/services/#user

Did you do a full system reboot between uninstall and reinstall? Thats typically required to fully uninstall a plugin.

Were you previously able to create, destroy, and update stacks on unRAID 7.1.0-rc3? What do you see on the in the terminal if you run the command "docker compose version"? Have you tried bring the stack down and then back up?

I pushed another update for you to try.

I pushed an update to the plugin. I am not sure that if it will do anything to fix your issue, but could you try it out and report back?

No you got it, the first was the correct command. It looks like compose (as in the docker compose package not the compose manager plugin) is not being found. I suspect this may be an issue with this plugins compatibility with unRAID 7.1.0-rc3 (which has not been tested yet). I will try and look into this further tonight. Thanks for your help.

Ah no i meant, if you run the command "docker compose version" in terminal what does it output.

What does the command "docker compose version" return?

Those commands look correct. What version of unRAID are you running?

On the compose manager settings page there should be an option to enable debug logging. If you enable that option then you should see the compose commands that are being run output to the log. That might provide more information for tracking down the issue.

I am not sure i agree with the term "unrealistic" however it is worth noting that outside of ZFS triply redundant RAID levels do not appear to be widely available (aside from mirror setups). Now that would mean having support in unRAID would be a stand out feature, but it also likely indicates that such a feature could be quite challenging to implement.

Yes plugin "reinstall" on every boot that's just how the unpaid plugin system works. You could try to activate additional logging from the compose plugins settings page. That might help you learn more, but based on that log snippet it looks like the plugin is trying to start the stack, so perhaps the stack itself is failing? Does the stack have any external dependencies, specifically on docker networks created outside of its compose file. If so look into the option to recreate the stack on star in the settings page.

Yeah "folders" are just a visual thing not an actual grouping of containers, I dont know if there is a way to set limits across a group of containers in docker.

I am not really sure what the above is about, but i can absolutely get behind having dedicated template box for memory limits.

Those labels are useful for scripting as well. Some of dockers cli commands include a filter option which can filter containers by label or the contents of a label. For containers started by compose you could use the contents of the labels to reconstruct the flags needed for a docker compose command (look at the --format option of docker inspect for how to easily pull values from specific labels). The fact that the docker compose command line doesnt natively do this for a lot of its commands (other than the commands that create a stack in the first place) has frustrated me for a while.