A retried Magento 2 git deployment reuses its build

You can now paste a screenshot, or drop files, straight into a ticket reply instead of saving and attaching them. Each file is listed with a preview before you send, and you can remove any you did not mean to add.

Every deployment that has not finished now has a Cancel button at the end of its row in the deployments list, on an environment's Deployments tab and on the Deployments page. A deployment that is queued or waiting to be run can now be cancelled, as well as one that is running.

Delete cluster now removes every site, environment and snapshot on the cluster, then its nodes. Before you confirm it lists everything that will be deleted.

If Google Cloud runs out of the usual Arm machines (C4A) in a region while your new managed cluster is being set up, its nodes are now created on the next Arm machine type (N4A) instead of the setup failing. The cluster page shows the machine type your nodes run on.

If Google Cloud runs out of the usual Arm machines (C4A) while a package change creates your cluster's new node pool, the new pool is now created on the next Arm machine type (N4A) instead of the change failing. Your sites move only once the new nodes are ready, as before.

When a deployment failed part way through, the site's scheduled tasks (crons) could stay switched off until someone retried or stopped it. The Control Panel now switches them back on as soon as a deployment fails.

Staging-only site pages now use the visible environment for page-scoped URLs, authentication, settings, and activity while retaining the hidden root as the group reference.

When a Magento 2 site deploys from git, its code is now compiled with the site's own PHP version before it goes live, using your Magento Marketplace keys from Company settings when the project needs them. Before this, these deployments stopped at the build step.