deployment-pipelines-authoring-cli

Resolve the source and target stage IDs by listing pipelines and filtering with JMESPath, then POST to /deploymentPipelines/{id}/deploy with the stage IDs and an optional items array. The deploy returns 202 with an operation ID that you poll at /v1/operations/{operationId} until it reaches Succeeded or Failed.

Fabric has no compare API, so list stage items for both stages, pair them by targetItemId, fetch getDefinition for each paired item, and diff them with the included diff_item_definitions.py script. Then submit a selective deploy with only the new and changed items.

You need the Admin role on the pipeline for all operations, plus workspace roles: Admin on the workspace for assign/unassign, and at least Contributor or Member on both source and target workspaces for deploys. Deploy also requires the Pipeline.Deploy delegated scope.

A pipeline runs only one deployment operation at a time, so starting a second deploy while one is in flight returns this HTTP 400 error. Poll the current operation to a terminal state before starting the next promotion.

No, deployment rules and parameter rules are configured only in the Fabric portal UI; there is no REST API to create or read them. Unassigning a workspace also permanently deletes that stage's rules and deployment history.

No, a selective deploy with an items array does not remove items deleted from the source stage. Use a full deploy by omitting the items array to propagate deletions, or delete the target item manually.