change deploy logic to stop-first instead of start-first #53
Reference in New Issue
Block a user
No description provided.
Delete Branch "stop-first"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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)