v0.7.0

v0.7.0 - 2026-08-23

Changed

• A failed blue-green release now reads as one release rather than as a row in a table of services, and it ends on what is serving. It used to open with "1 service(s) failed" above a list of three container apps — the staged side is one unit of work, so the count was right and useless — and it never said the one thing worth knowing first: that no traffic moved and the previous version is still up. The failure now names the phase it died in (the release failed while staging blue after 10m38s), lists a line per target, and closes with No traffic moved: green still serves the version it served before, and the blue revisions were switched off — or, when the cleanup itself failed, says that instead rather than offering a reassurance the list below it contradicts. A switch that fails says the traffic is back on the side it came from, and an after hook that fails says the deploy worked and nothing was rolled back, because that is the opposite situation and used to look identical. The cleanup also prints as it goes: abandoning a side was silent, so the answer to "is the staged side still running and still being charged for" was a trip to the portal. On Container Apps the line itself is shorter and says more. The app name was in it three times and the platform's own wording buried the fact — is Unhealthy — main is Waiting (Container is waiting with reason: CrashLoopBackOff on legion.), 5 restart(s) is now revision evolve-tst-discover--0000039 never started (container main: CrashLoopBackOff, restarted 5 times), followed by the az containerapp logs show command for that revision and that container, since whatever the process printed before it exited is the next thing to look at and it is not in the deploy log.
• bake_time is now refused on Container Apps and Cloud Run instead of being read by nobody. It is the window before ECS terminates the old side, and only the ECS driver ever looked at it — set on either of the other two it parsed, validated and then did nothing, which is the one thing a capability is not allowed to do here: a rollback window someone wrote down and did not get is exactly the outcome they were trying to rule out. Both refusals name the setting that answers the same question on that platform — keep_warm on Container Apps, and on Cloud Run nothing, because a revision that keeps its tag at zero traffic is already the window and stays available until the next release takes it.

Fixed

• A Container App revision whose container dies on start now fails the release in about a minute instead of running the wait out to its ten-minute deadline. Container Apps leaves such a revision in Processing — it is still restarting the container, so by its own account nothing has gone wrong yet — and the wait believed it, because the fact that settles the question lives a level down: the replica's restart count. That count was only ever read once the revision had already admitted to being Degraded or Unhealthy, which for an image that exits immediately can take the better part of the deadline it was supposed to pre-empt. The replicas are now read on every poll while a revision is not yet serving, and a container past its third restart ends the wait whatever the revision says about itself — with the same message as before, naming the container and the command that shows what it printed. A container that is merely slow is unaffected: it has not died, so there is nothing to report and the strike count stays where it was.