You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Database migrations are problematic when you can't run command in your container after a deployment (for a multitude of reasons). Even if you can, it adds compexity to your continuous deployment pipeline.
It might needs some testing but database migration should work if ran on each container start.
A nice way to make this optional and customizable would be something similar to "site-enabled"/"site-available" but with bash scripts that would be ran by the container if present.
Then this image could provide with some classic use cases like doctrine migrations.
Also this would be a good place to put a "dirty" permissions fix and removing it from the default behavior of this image as it's taking time while not being needed most of the time. As a matter of fact, it should never be needed if all the operations involving Symfony's commands are done as www-data (something we should add to the doc). The only good place a "permissions set" might be is the end of the Dockerfile.
The text was updated successfully, but these errors were encountered:
You could try using a different entrypoint.
create a entrypoint.sh
#!/bin/sh
exec ${@}
and in the Dockerfile:
....
RUN mv /entrypoint.sh /run.sh
ADD entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/run.sh"]
Database migrations are problematic when you can't run command in your container after a deployment (for a multitude of reasons). Even if you can, it adds compexity to your continuous deployment pipeline.
It might needs some testing but database migration should work if ran on each container start.
A nice way to make this optional and customizable would be something similar to "site-enabled"/"site-available" but with bash scripts that would be ran by the container if present.
Then this image could provide with some classic use cases like doctrine migrations.
Also this would be a good place to put a "dirty" permissions fix and removing it from the default behavior of this image as it's taking time while not being needed most of the time. As a matter of fact, it should never be needed if all the operations involving Symfony's commands are done as
www-data
(something we should add to the doc). The only good place a "permissions set" might be is the end of the Dockerfile.The text was updated successfully, but these errors were encountered: