All updates

Rapids Fixes: Image Checks, Rollbacks, Git Builds and Emails

Rapids now refuses malformed image references, reports a deployment as successful only when it is ready, rolls back a stuck one, and fixes Git builds, container names and repeated failure emails.

Version 2.9.162Bug fixRapids

What's changed

  • An incomplete image reference, such as cr.danubedata.ro/my-team/ with no image name, is now refused by the Create and Edit forms and by the API before anything is deployed. It used to pass the check, turn into an unusable :latest reference and fail later when the image was resolved
  • Checking a public image on ghcr.io, or on another registry that answers an anonymous request with a token challenge, no longer reports Registry requires authentication. A private or missing image with no credential attached still does
  • A deployment now counts as successful only once its new revision is ready. Until then it stays in progress with no traffic, the previous deployment keeps serving, and the success is recorded in your audit log only when the revision is ready
  • A rollout that is still not ready after 30 minutes is abandoned and, when an earlier working configuration exists, the container goes back to it. That rollback used to fail on the container's sizes, so the container kept the broken configuration. The Startup deadline (seconds) setting, under Advanced in the Runtime section of the Edit page (30 to 1800), sets how long a new revision has to become ready before the rollout is marked failed
  • Building a container from Git with a stored access token or SSH key no longer fails from its second build on. The build stopped before it started with a 409 conflict error and the container was marked as errored
  • A container that recovers briefly between crashes no longer emails you at every crash: the first failure still emails you, later failures and health alerts about the same container share one cooldown, and a failure after 30 minutes of steady recovery emails again. In-app notifications continue as before
  • Two projects can now use the same container name, because a name only has to be unique within your project. Creating a container with a name another project uses used to fail, and a duplicate inside your project is refused with a clear message even when two requests race