mstrhakr

Thank you for the report. I've also noticed some of these issues with the UI keeping up with what's happening. I'll be doing some work on this next to be included in the current beta soon.

This is fixed in the latest beta if you are willing to try that out.

For your first question, this is controlled by a docker label entry, in Compose Manager Plus its handled by the override/labels section. Basically you have to specify the label net.unraid.docker.managed as composeman otherwise it shows up as 3rd Party in the UI. This is normally handled automatically but very much depends on how you have it all configured. If you are using a manual override setup, that is one way this could be missed. services: docker-container: labels: net.unraid.docker.managed: 'composeman' Compose has its own updates you can configure, sounds like there are still templates with the same name as the running dockers that are now Compose controlled. This likely is causing Unraids updates to try updating them. I will need to confirm this, but I would imagine using new container names would unlink them from their previous incarnation as a Docker Template and thus stop Unraid from trying to update them. I noticed this on a few of my containers but haven't tracked it down yet. I will look into the update issue, if you can please add an issue on GitHub about it.

This is also fixed but the fix is in the latest beta of Compose Manager Plus, the issue was related to the editor modal tabs causing the Network tab to remain hidden when selected.

Thanks to everyone who reported the stuck “pending” entries, duplicate-endpoint errors, and failed container updates. The plugin’s use of Post Arguments for network persistence was the wrong approach, and I’m moving away from it entirely. I’ve committed changes for the next release: Unraid 7.4 and newer: additional attachments use Unraid’s native Additional Networks field. For prerelease builds, this requires 7.4.0-beta.1.2 or newer, which includes the container-update restoration fix. Earlier Unraid versions: container attachment changes are disabled. Network inspection, creation, and metadata editing remain available. Post Arguments are left alone: the plugin will no longer add, remove, or migrate network commands there. If reconnect commands are detected in existing Post Arguments, a warning will identify the affected containers. Attachment changes through the plugin will be blocked for those containers to avoid adding conflicting configuration. Those commands may have been added manually, so the plugin will not assume ownership or remove them. This does not automatically repair existing Post Arguments. Review affected containers in Unraid’s container editor, and don’t indiscriminately clear unrelated arguments. Deleting networks or rebuilding docker.img does not remove commands saved in container templates. The changes also correct pending counts and distinguishes attachments awaiting container recreation from live connections. A plain container start does not apply newly saved Additional Networks.

I took a closer look at this and confirmed regression from the 09.13 update (#149 change made rebuilds opt-in, so local-only images hit a registry pull). Fixed in the next beta now: if the pull fails, buildable services are skipped and rebuilt from source automatically. The per-stack "Rebuild Images on Update" save bug is also fixed. With pull_policy: never, enable that per-stack toggle (or use pull_policy: build) to force a rebuild.

We are working on Git based stacks which may include a webhook based deployment. We just started (by we I mean a contributor) so the beta only includes CLI based git stacks right now, no UI. Keep an eye out though. Beyond that, if you only want it to poll regularly, I would probably get it down to 15 minutes, I will look into this.

This is interesting, one thing I am always thinking though is, 'Is this worth doing considering Unraid 8 will have a whole new base OS, layout, and built in compose support.' In this case, I'm not sure because I don't use secrets like that. With that said, I love contributions and would be happy to have you submit a PR for this if you think its worth tackling. I did just add credential management in dev to support private github repos and such so you may have some scaffolding available to reuse now.

To be honest, I wish this was versioned like a normal program. Just forcing an update to latest with out much choice and no way to roll back is not fun for me or the users. Hopefully they rethink this as part of the rebuild they are doing for Unraid 8.

Updates 9/3 and took care of these issues.

Yes, it populates the list by scanning the projects folder. Deleting the old one is perfectly safe.

Was this after an update to anything relavent? There was an issue I had with websockets dropping due to a Chrome update enforcing HTTP/2 standards but this seems different. Please open a bug report on GitHub and I can take a closer look.

I'll have a beta out soon that removes the docker.manager update checking as it seems to be a bit unreliable, there is a post here about it. I copied that and fixed a couple things and it is now owned by compose manager so updates that dont exist should be completely fixed going forward. (Once the beta and then the next stable are released)

Do you just want to update it to the latest? This needs done by me when the plugin is packaged it grabs whatever version is in there. Its not something you can change at runtime. I'll test updating it to the latest 5.4.0, though I usually like to wait for at least a x.x.1 before updating. AND I've been awol for a bit dealing with life so I haven't had a change to do any updates.

You mounted the docker socket so it's showing all the dockers running on your server. It's using unraids install of docker, not its own docker in docker setup or something.