V3 console: Can not deploy multiple services in parallel / update all at once + github version mismatch

Hey!

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:
image

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 :confused: ?? 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:

  1. Is there an option in V3 to update multiple services at once in V3?
  2. 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.
  3. Is the git commit change intended, although the deployment was not scheduled?

Thanks in advance :blush: !

Best,
Peter

1 Like

Hi Pierre,

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?

thanks

Thanks @a_carrano , looking forward to the feature entering V3 :slight_smile:

And also thank you for the V2 URL!

Here are the IDs of the env/service:

  • Environment ID:
    • 1c20408c-68d2-4a36-8e60-bbe50f74a973
  • Service ID:
    • 62cde153-766e-41fa-9000-c98cf76a1a77

Thank you!

Best,
Peter

Hi @pierre_at_valuecase ,

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 makes sense. Thank you for the explanation :slight_smile: