Workflows and controlled deployment

Reuse one Session while you develop a command sequence, then record the accepted sequence as a workflow. When installation needs a reviewed handoff, plan a destination-specific bundle instead of asking the installer to reopen and reinterpret source.

Continue the working Landing/Operations project and workspace-development.yml. If you added the native model, Report and source-backed models, retain those bindings too; the Power BI Build below operates those local definitions. Omit that Build when your project has no Power BI items.

Open one Session

weaver session --workspace-config workspace-development.yml --timings

At the weaver> prompt, run the normal installed-project sequence:

weaver> check
weaver> build --item Lakehouse/Landing --item Warehouse/Operations
weaver> build --item PowerBI/Parcel --bind-data-sources
weaver> load
weaver> test
weaver> health
weaver> exit

Source-data and model/Report Build calls remain separate. Reports deploy after their model and have no Load/Test step. Each command uses the ordinary parser and selection rules; the leading weaver is optional at the prompt.

The Session belongs to one physical workspace and reuses healthy capabilities it has acquired, such as item resolution, Warehouse connections, OneLake access and Spark context. Unneeded capabilities are not started. A failed command returns to the prompt; completed work remains applied. --timings reports Fabric access timings on exit, not a new Load execution mode.

Turn the accepted sequence into a workflow

Add verify under the existing workflow.yml workflows, keeping your other workflows:

workflows:
  verify:
    - check
    - build --item Lakehouse/Landing --item Warehouse/Operations
    - build --item PowerBI/Parcel --bind-data-sources
    - load
    - test
    - health

weaver workflow verify --workspace-config workspace-development.yml --timings

Weaver parses the entries, resolves one workspace, displays the numbered sequence and asks once for confirmation. Review and confirm if correct; decline if not. Commands run in file order through one Session. Load/Test outcomes share a workflow identifier for catalogue correlation.

An execution error stops later entries. Test/Health findings are collected while later commands continue, then make the completed workflow unsuccessful. Completed work is not rolled back. A workflow is an ordered list of Weaver commands, not a shell or a transaction. Session and workflow concepts and Workflow behaviour own context reuse and exact continuation rules.

For unattended execution, provide credentials and authorise the settled sequence explicitly:

weaver workflow verify --workspace-config workspace-development.yml --yes --non-interactive

--yes authorises the workflow and entries. --non-interactive separately disables input, keypress waits and browser sign-in. Desktop authentication can use a configured service principal or an existing Azure CLI sign-in; the selected identity still needs permissions for every capability. Store secret material in the runner’s secret store, not the project or bundle. Piped y is not authorisation when stdin is not a terminal. Automation and execution contexts explains credential selection, host boundaries and machine output.

Keep the lifecycle in Fabric when that is the execution host

A Fabric notebook can call weaver.build(), weaver.load(), weaver.test() and weaver.health() using its attached workspace, runtime and identity. The source-data catalogue remains explicit; discovering the workspace does not invent one. Explicit Session construction is optional for context reuse, not a prerequisite for an ordinary attached-notebook call.

Portable execution between desktop and Fabric shows notebook Resources layout and native execution using Landing/Operations source. Keep the same authored project when changing execution host. Fabric Git’s Resources support remains separate: fabric notebook push transports a notebook definition, not local Resources.

Desktop Lakehouse Build/Load/Test needs the matching published Weaver runtime; the attached-notebook path uses its active Spark session. Running Python in Fabric explains publication. Fabric scheduling, capacity, identity and retries remain host responsibilities.

Hand off frozen installation work

Use a bundle when the installer should execute reviewed work without reopening the project:

Check source → plan bundle for destination → review and transfer → Install → Load → Test → Health

build --bundle-only reads the intended destination catalogue and inventory, then freezes targets, ordered actions, generated payloads and integrity hashes. It needs destination access despite not installing. It cannot be combined with --dry-run, and neither mode provisions missing Power BI targets as an ordinary first Build can.

Generate a separate bundle for each destination. Changing a configuration does not retarget a retained bundle. Transfer its complete manifest and payload tree without editing them; credentials are not included. Install validates the representation and checksums, then executes frozen actions without rereading source, recalculating impact or substituting targets from another configuration. If source, bindings or relevant destination state changed, plan a new bundle.

A failed installation stops later sequences but does not undo completed physical changes. After installation, operate the destination’s installed definitions with Load, Test and Health. Build bundles and controlled installation explains the handoff; build, install and the bundle format own exact syntax and representation.

For machine consumers, use each command’s advertised structured output and process status together, retaining diagnostics separately. There is no universal JSON envelope or promised long-term compatibility for unversioned output. Machine-readable output records the command-specific boundary.