When we canceled a deployment it’s not possible to redeploy because environment is in state canceled. For that we have to let the deployment failed to be able to deploy again and we loose time when container can’t start or is in crash loop.
It is possible to enable deployment when environment is in state canceled ?
I wasn’t able to reproduce the issue you are describing. I have tried to cancel the deployment of an environment and I can relaunch a deployment right after (once my environment deployment is flagged as “cancelled”)
Can you give us more detail on what you have done exactly?
I use the Qovery github action to deploy my application. In my workflow I specify all the applications id that I need to deploy. I have 3 applications with the same code base that are deploy in same time (I can’t wait parallel deployments ). All were in crash loop and 2 of them in failed state because of too many crashed. So I cancel the last one deployment to save some time because it’s in crash loop too but not in failed state.
I push my fix to prevent container to crash and deploy again. And in my github action I have this message : Environment cannot accept deploy yet, state: CANCELED
On top of being always updated in your pipeline (since the script downloads the client), you will find all the latest updates on the CLI (we will invest more in the CLI integration)
Hi again @a_carrano, I tried to migrate my CI using the CLI but I’m faced with a problem. My application is configured from a github repository with auto-deploy set to false. On the Qovery Cli using container deploy I think we have to use an application with application source set to Registry instead of git provider. I can’t find how to migrate an existing application to application source container without creating a new one. How can I handle it ?
And other question, I have 400 bad request on Qovery Deploy command from Cli and can’t find why. It is possible to run it with debug mode or in verbose mode to get de real error message ? I tried with organization / project / environment and container name and id
Hi @Orkin , unfortunately, it’s impossible to migrate your app from a git-based repository to a container one. The reason is that it does not rely on the same configuration under the hood. So you will need to create a new application. Maybe we can thing to provide a migration helper via our product if it happens often - cc @a_carrano
You have to use names and not IDs (it’s more convenient). If you have space in your resource names - double quote them E.g qovery container deploy -n "App Name"
If you have used a scope like Project or Environment then you don’t need to export env vars and secrets. Otherwise, you’ll need to re-import them.
@rophilogene I can put anything in all values I’m always faced in 400 bad request event when data are invalid. It don’t trigger the deployment state on the cluster
I take a look at your configuration - and your container uses a tag name develop at the moment. You must provide a valid tag name with the parameter --tag. BTW, I highly recommend using a unique tag name per image. develop is not a unique tag name, and you can have consistency issues between redeployments.
Yes I can change that, I have to put one on service creation interface and though it will be already the same but I think it’s only for initial deployment right ?