Feature Request: Extend cli with '-wait-for-readiness'

[onionhammer]

Is your feature request related to a problem? Please describe.
Currently when you create a new revision, The CLI will simply return successful when the new revision is created. The problem is, during a CI/CD process where a revision is automatically created, it would be nice to know if the revision started successfully before returning a success code.

Describe the solution you'd like.
Now that zero downtime deployments appear to be working, I propose a new flag added to CLI commands such as 'az containerapp revision copy' called '-wait-for-readiness' which will keep the CLI running until the timeout specified by the probe or it returns successfully, then change the exit code correspondingly to whether the probe succeeded.

Describe alternatives you've considered.
The alternative is to retrieve the host name of the new revision and ping the startup probe, assuming it's externally accessible.

[JonasSamuelsson]

@ahmelsayed @anthonychu Do you have an ETA on this?

[onionhammer]

Would still love an ETA on this - would simplify automated deployments a ton

[onionhammer]

@ahmelsayed @anthonychu Any update on this?

Obviously there's that new github action, which I'm sure uses Oryx, which adds gigabytes of unnecessary/redundant bloat/compilers

[JonasSamuelsson]

@ahmelsayed, @anthonychu, @BigMorty Do you have any update on this?

If not it would be nice if you could point to some docs/information on what you see as the best way to make sure that a new revision is up and running.

[onionhammer]

@JonasSamuelsson if you're using CI/CD, you could use the (unfortunately/unnecessarily oryx bloated) Github actions.

[JonasSamuelsson]

@onionhammer The image is already built in a earlier pipeline step, all we're doing is az containerapp revision copy ... and I would like it to wait until the new revision is up and running.

[IhorHolovatsky]

I would love such --wait-for-readiness flag in az containerapp update cli command as well. So that will help to fail the CD pipeline if revision is successfully created, but the image continuously crashes during startup.

Our container app is not externally accessible, so an alternative approach to invoke the readiness endpoint from within the CD pipeline is not an option.

Example:

az containerapp update -n $containerName -g $containerRg --image $image --wait-for-readiness

[onionhammer]

Any update on this?

[onionhammer]

I've actually switched away from using the containerapp CLI command, since it's too limited to allow for updating initcontainer images. az resource update does a better job with just about the same amount of code

[ProTip]

@onionhammer Do you have a workaround for this using that paired with az resource wait? This is a big hole in reliability for me(not knowing in the workflow if the revision succeeded or failed to provision) so I'm looking at piecing this together now..

[onionhammer]

Just polling until the new revision is healthy during the deployment