start-first allows for zero-downtime updates, but can lead to resource contention between old and new containers (which is maybe why we were seeing unable to lock level db at /var/lib/gitea/data/queues/common: resource temporarily unavailable in the error log in the issue mentioned).
not totally sure about this, but the theory makes sense to me, and the app was able to successfully deploy after the change
I believe that this change fixes the issue described here: https://git.coopcloud.tech/coop-cloud/gitea/issues/52
I believe doing `stop-first` instead of `start-first` causes the old container to be stopped before the new one is started (see: https://docs.docker.com/reference/compose-file/deploy/#update_config).
`start-first` allows for zero-downtime updates, but can lead to resource contention between old and new containers (which is maybe why we were seeing `unable to lock level db at /var/lib/gitea/data/queues/common: resource temporarily unavailable` in the error log in the issue mentioned).
not totally sure about this, but the theory makes sense to me, and the app was able to successfully deploy after the change
i just tested it with forgejo and it works! i can see in the logs that the container receives the shutdown signal and then it starts the new container. i didn't even had to restart abra app logs
i just tested it with forgejo and it works! i can see in the logs that the container receives the shutdown signal and then it starts the new container. i didn't even had to restart abra app logs
i don't think you need to bump the version on the pr itself, because this will be done by the abra recipe upgrade gitea step, and it will complain there's nothing to do
i don't think you need to bump the version on the pr itself, because this will be done by the `abra recipe upgrade gitea` step, and it will complain there's nothing to do
@fauna for some reason I have been in a habit of making the git tags manually instead of using abra recipe upgrade but maybe i should start using the actual tool (i think makes same result in the end though)
@fauna for some reason I have been in a habit of making the git tags manually instead of using `abra recipe upgrade` but maybe i should start using the actual tool (i think makes same result in the end though)
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I believe that this change fixes the issue described here: #52
I believe doing
stop-firstinstead ofstart-firstcauses the old container to be stopped before the new one is started (see: https://docs.docker.com/reference/compose-file/deploy/#update_config).start-firstallows for zero-downtime updates, but can lead to resource contention between old and new containers (which is maybe why we were seeingunable to lock level db at /var/lib/gitea/data/queues/common: resource temporarily unavailablein the error log in the issue mentioned).not totally sure about this, but the theory makes sense to me, and the app was able to successfully deploy after the change
cc recent committers if you have any thoughts or extra knowledge about this @3wordchant @fauno @p4u1
i just tested it with forgejo and it works! i can see in the logs that the container receives the shutdown signal and then it starts the new container. i didn't even had to restart abra app logs
@notplants LGTM!
@@ -88,3 +88,3 @@- "traefik.http.middlewares.${STACK_NAME}_cors.headers.accesscontrolmaxage=100"- "traefik.http.middlewares.${STACK_NAME}_cors.headers.addvaryheader=true"- coop-cloud.${STACK_NAME}.version=3.5.2+1.24.2-rootless- coop-cloud.${STACK_NAME}.version=3.5.3+1.24.2-rootlessi don't think you need to bump the version on the pr itself, because this will be done by the
abra recipe upgrade giteastep, and it will complain there's nothing to do@fauna for some reason I have been in a habit of making the git tags manually instead of using
abra recipe upgradebut maybe i should start using the actual tool (i think makes same result in the end though)