When I clone an environment from a blueprint environment, I’m expecting it to pull the latest commits from the branches that the services are pointed at. It looks like what I’m actually getting is commits from when the blueprint environment was created, so those commits are old and getting older all the time.
Today I cloned the blueprint, went into the new environment, and re-selected the branch, to see if that would trigger pulling the latest commit on the initial deploy. But I still got the old commit.
I was able to get the right commit deployed using the “deploy other version” option, but is there an easier way to get a new environment to use the latest commits from the branches it’s using?
To provide you a tailored answer I need to know if you let Qovery managing Preview Environments for you? Or did you make an integration with our CLI into your CI?
I am using Preview Environments and they’re awesome, but I also sometimes need to set up an ad hoc environment for something that isn’t triggered by a PR. In either case, except in the case of the triggering feature branch for an automatic Preview Environment, I think it would be ideal if the services started out with the latest commit from the branch in the blueprint env.
I think it makes sense and it could be an option we had to let you choose if Qovery should use the latest version or not (per service) for the preview environment. In the meantime, you need to change the version of your services inside your blueprint environment. Something you can do as well, is a “tooling” project where you put a cronjob that will automatically update the version of your blueprint services via the Qovery API. If you want I can write and provide you the script
indeed we should add an option allowing you to let the cloned env point to the head for each application.
Edit: the one I provided below is the wrong solution. the auto-deploy will trigger the deployment of your blueprint and that’s something you probably don’t want
What you can do right now is to activate the “auto-deploy” feature on your blueprint env (Env settings > Deployment > Rules). With this feature activated, even if the blueprint environment is not running, the commit id of the applications will be updated (and thus any cloned environment will point to the latest commit)
What you can do right now is to activate the “auto-deploy” feature on your blueprint env (Env settings > Deployment > Rules). With this feature activated, even if the blueprint environment is not running, the commit id of the applications will be updated (and thus any cloned environment will point to the latest commit)
The only thing you have to do is to deploy once the blueprint and then stop it. In this way, we won’t trigger the deployment of your blueprint.
Thanks @a_carrano, I will give that a try. I had auto-deploy disabled because I thought it would cause the blueprint environment to get turned on automatically.
And thanks @rophilogene for the offer of the script!
