--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):Semantics
- One executor, two entry points. A direct bake and an approved
BakeActionchange-request use the same executor. Both requirebake.createplusservice-profile.assume, andworkspace.usefor workspace bakes. A workspace bake’s cloud identity must admit the workspace throughworkspace_use; a tenant-level bake instead requiresplacement-sa.assumeon that identity. The authority belongs to whoever executes the bake, either the caller or the approver. Proposing requires onlychange-request.createplusrecipe.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-newto 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
BakeActionchange-request per distinct configuration in your bake history (source: recipe_bake), so a reviewer approves each re-bake against the new content. Track executions withmurmur bakes ls.
Errors
Related
- Images: concept overview
- Recipe: what a recipe defines
- Change requests: review and apply proposed bakes
murmur bakes ls: track bake progress