We have a prod environment that we used to deploy manually using V2’s “Update all” feature. That was very neat, as we were able to deploy the latest version of every service once a feature was complete.
In V3 this I wasn’t able to find a way to do the same … and as V2 now redirects to V3 by default, there’s no way to do that anymore.
Then I tried to update each service manually in parallel. So I clicked
“Deploy other version” for service A, chose the latest git commit and clicked “deploy”
… afterwards I clicked “Deploy other version” for service B, chose the latest git commit and clicked “deploy”.
Then I got the following error message:
Then I waited for service A to finish.
So I revisited the V3 console some minutes later and water to use “Deploy other version” of service B. But that option was not available.
The console said, the service already points to the latest git commit ?? That was very weird. So I clicked “redeploy” hoping the correct git commit has been deployed.
Summary:
[Feature request] We are missing an “Update all” function to update all services at once.
[Bug report] The stopped “Deploy other version” action of an other service has been stopped, but did cause the git commit pointer to change of service B.
I have three questions:
Is there an option in V3 to update multiple services at once in V3?
If not: Do you plan to add that feature again? For us it is very important, because some non developers need to regularly deploy prod and require a simple way to do so.
Is the git commit change intended, although the deployment was not scheduled?
indeed it’s something that is missing and it will soon be available again on the V3! We should be able to have it back either by the end of this week or next week.
In the meantime, if it gets really painful/blocking for you, you can get temporary access to the V2 using this URL. IMPORTANT: this is a temporary application (not the production one) that will be dismissed when the “update all” feature will be available again.
regarding your strange behaviour on the app pointing to the wrong commit, I’ll investigate further. Can you tell me in which environment/application you did this action?
so I have checked and this is the expected behaviour.
When selecting a new version, you are declaring a new “target version” for your application, this is the version you see on the service table. This is exactly the same behaviour as the other settings of your app: a change on the CPU/RAM is applied only after correctly deploying this change. If a deployment of that CPU/RAM change has failed, we are still displaying the desired configuration of the CPU/RAM (and alert you that you need to re-deploy to apply the changes)
This means that when your deployment of the other version has failed, we have updated the target version and it will be the one used when you trigger a re-deploy
I agree that this part might be misleading, I’ll see how we can improve this part on the interface!
?? That was very weird. So I clicked “redeploy” hoping the correct git commit has been deployed.
!