API keys limited to a compartment reach only that compartment's sandboxes
On Runtime 2.0, a key limited to one compartment (project) now lists only that compartment's sandboxes, and GET, DELETE, :exec, files, processes and every other sandbox route return 404 for a sandbox in another compartment, the same response as for a sandbox that does not exist. A sandbox created on Runtime 2.0 before this change has no recorded compartment: a compartment's key reaches it only if that key created it. Account-wide keys still reach every sandbox in the account. A create with a name that a sandbox the key cannot reach holds returns 409 name_taken without naming that sandbox, and getOrCreate never returns it.
Same day.
- Sandboxes: exec on a newly created sandbox returns as soon as the command exitsIn some regions, POST /v1/sandboxes/{id}/exec on a sandbox created at the default size could hang until the client's timeout.
- CI/CD: a failed job's reason names its first errorThe reason shown for a failed job, in the console and on its GitHub check run, was the last line of its log, which for a build is often a…
- API v2: filter sandboxes and other machines by phaseThe lists of sandboxes, browsers, desktops, dev environments, databases, Kubernetes clusters and notebooks (GET /v2/{resources}) accept p…
- API v2: lists return the API v1 ID of each moved resource with include=movedFromEvery v2 list (GET /v2/{resources}) accepts include=movedFrom, which adds movedFrom to the page: the ID of each item that moved in from A…
- API v2: lists return each resource's usage to date with include=usageA list of a metered resource (GET /v2/{resources}, for every resource that has :usage) accepts include=usage, which adds usage to the pag…
- API v2: lists return resources newest first with order=newestEvery v2 list (GET /v2/{resources}) accepts order=newest, which returns resources by createdAt, newest first, and pages with cursor as be…
- Sandboxes: commands run as the sandbox user, and the HTTP proxy works at every sizeOn some sandboxes, commands, processes, terminals and file writes ran as root even though the sandbox reported user: "sandbox".
- Sandboxes: bucket mounts succeed and stay mountedPOST /v1/sandboxes/{id}/mounts checked whether the mount's client was still running by the size of its cgroup's process list, which the k…
- Sandboxes: sessions work for every sandboxPOST /v1/sandboxes/{id}/sessions, GET /v1/sandboxes/{id}/sessions and POST /v1/sandboxes/{id}/sessions/{sessionId}:revoke now work for ev…