Skip to main content
Bakes a recipe into a VM image. By default the bake executes immediately under your own authority via the imperative Bake API. No change-request is created. With --propose the same content is staged as a BakeAction change-request, left PENDING for a reviewer whose approval runs the identical executor.

Synopsis

<recipe> is the name of the recipe to bake.

Flags

Output

The command prints one line to stdout:

Examples

Bake now (executes immediately):
Propose a bake for someone else to approve:

Semantics

  • One executor, two entry points. A direct bake and an approved BakeAction change-request use the same executor. Both require bake.create plus service-profile.assume, and workspace.use for workspace bakes. A workspace bake’s cloud identity must admit the workspace through workspace_use; a tenant-level bake instead requires placement-sa.assume on that identity. The authority belongs to whoever executes the bake, either the caller or the approver. Proposing requires only change-request.create plus recipe.read. A direct bake creates no change-request record.
  • Idempotent. The bake workflow ID is deterministic from the recipe content, so re-issuing identical content joins the running bake or no-ops on the cached image. It never double-bakes. Use --force-new to bake identical content fresh.
  • Validated up front. The full spec (base image for the placement’s substrate, machine-type region availability, service-account binding match) resolves before anything runs, and resolves again at execution for proposals, so an unbakeable request is rejected immediately.
  • Automated re-bakes. Modifying a recipe’s bake-consumed fields auto-proposes one BakeAction change-request per distinct configuration in your bake history (source: recipe_bake), so a reviewer approves each re-bake against the new content. Track executions with murmur bakes ls.

Errors