murmur bake

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.

murmur bake <recipe> --environment ENV --placement PLACEMENT --service-profile PROFILE [flags]

Flags

Flag	Required	Description
`--environment ENV`	yes	Environment providing the scratch VM machine shape.
`--placement PLACEMENT`	yes	Placement where the image is baked.
`--service-profile PROFILE`	yes	Service-profile whose credentials the bake VM uses. A bake never carries your personal secrets; executing requires `service-profile.assume` on the profile.
`--service-account ID`	conditional	Cloud IAM identity for the bake VM. Required whenever the placement has service-account bindings — the action pins the exact identity, never a server default. Executing requires `placement-sa.assume` on it.
`--force-new`	no	Skip the image cache and bake fresh. Without it, a bake whose computed image already exists is a no-op.
`--propose`	no	Stage a change-request `PENDING` for review instead of executing.
`--rationale TEXT`	no	Rationale recorded on the change-request (only with `--propose`).

Examples

Bake now (executes immediately):

$ murmur bake go-python --environment default --placement us-central1 --service-profile infra-bot
bake of recipe go-python started (run 019f4368-…); track with: murmur bakes ls

Propose a bake for someone else to approve:

$ murmur bake go-python --environment default --placement us-central1 \
    --service-profile infra-bot --propose --rationale "toolchain bump"
created change-request cr-a1b2c3 for bake of recipe go-python (pending review)
$ murmur change-request approve cr-a1b2c3   # a reviewer with bake.create + assume

Semantics

One executor, two doors. A direct bake and an approved BakeAction change-request run the same executor with the same authority: bake.create plus service-profile.assume (and placement-sa.assume when a service account is pinned) — bound to whoever executes (the caller, or the approver). Proposing needs only change-request.create + 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 — for proposals, again at execution — 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.

Getting Started

Core Concepts

Guides

Flags

Examples

Semantics

​Flags

​Examples

​Semantics

Flags

Examples

Semantics