I’ve had the “problem” that I was wondering why my server would not work as expected despite my local version working just fine because I paused the service when I found an error, commited a fix and resumed it again but the resume didn’t check for new versions.
Resuming should be self explanatory. It temporarily stops the app from running. In order to update to the latest commit, you need to restart the app altogether. I personally think it’s best this way and it should not be changed.
Hmm, maybe but I feel like since it deploys new commits automatically while running I’d expect it to do as well when resuming
But your app is paused, meaning it stays in the same state. Why look for new commits? I expect a paused app to resume in the state it was before, not with a new commit. If I don’t care about it’s state, I’ll just stop it anyway.
From my perspective if I’d want my app to stay in the same state I’d just not commit to that repo or disable automatic deploys (which I’m not sure is possible rn) but when the default option is to always automatically deploy the newest version I’d expect it to update when it resumes
That’s not really a viable solution (not commiting). I’m not going to stop my git operations just because I want my app to stay in the same state for various reasons. I’ll just stop it and start it whenever I want.
Plus, resuming means it will start from the last known state. If Qovery does update to the latest commit, all that progress is gone anyway, because the container will need to be created, so why using resume when it’s all going to be gone anyway once I’m going to commit a new file?
I see where you’re coming from but then stopping the app whenever I want to commit and then resuming just so it doesn’t update is also a problem
Deployment rules will be coming in September if you want to stop automatic redeploys.
1 Like
Ah ok, maybe that’ll address this then
1 Like