Closed GringoDotDev closed 1 week ago
Happening to me too, would love to see this, it's such a great quality of life
Hey @andrasbacsai, could you take a look at this issue? I think it could be easily fixed since it already works on compose only deployments
It would be specially important for teams that want to back up their database to S3 in git + docker compose deployments
This is more of a feature request, so I am moving this to a GitHub discussion (as this has not been implemented). This will be included in the full backup manager that will be coming in the future.
Description
If you deploy a docker-compose.yaml as part of a git repository deployment, it doesn't seem to recognize things like mysql or redis as the database subtype. This means that you can't access things like database backups, etc.
This is a difference in behavior between pasting in the same docker-compose as part of the non-git workflow.
Let's take a simple example, let's say your docker compose looks like this:
If you paste that into the git-less deploy flow, the docker-compose will come out like this for the mysql container (excluding networks, volumes, etc. for brevity):
But if you set up an app using a git repo, the same compose will come out like this:
Not sure if it's the root cause, but notice the difference in the labels applied to the containers.
Net-net, instead of having a dashboard that looks like this:
With the ability to manage your db services like this:
You instead end up with this:
I'm motivated to get this fixed since it would unblock some cool deployment workflows for us (that I would also like to publicize on Youtube). I'm a pretty good Laravel dev but don't know this codebase particularly well. If you point me in the right direction I'm happy to make an attempt at a PR.
Thank you!
Minimal Reproduction (if possible, example repository)
Exception or Error
No response
Version
v4.0.0-beta.213