Changes in Docker compose configs not propagated to containers during compose up
#1490
Comments
|
This is seemingly being worked on in: docker/compose#11931 |
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 18, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 19, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
aequitas
added a commit
that referenced
this issue
Sep 19, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
mxsasha
pushed a commit
that referenced
this issue
Sep 19, 2024
…elevant containers Changes in 'configs' in docker-compose.yml don't cause containers/services to be restarted. This will be fixed in the future upstream but for now force recreate of relevant containers during deployments. #1490
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When changing the contents of
configs:in thedocker/docker-compose.ymlvia.envvariables those changes are not propagated into the containers when running acompose upcommand (eg: during deployment). This may also be the case with changes to theconfigsthemselves, not tested yet. Restarting the container also does not have the desired effect. The only thing that works currently is bringing the container (or the entire environment) down and up again (ie: recreating the container).A solution might be to include the variables in the container 'env' but this would only work for
.envvariable changes, not the rest of the config file.The text was updated successfully, but these errors were encountered: