Upgrading the CLI from v50 to v51

v51 is the release where sfp gains a server: from v51 the CLI runs against sfp server and is no longer standalone. If your pipeline runs sfp itself — a container: image: …/sfp-pro:… job in GitHub Actions, Azure Pipelines, Buildkite, or any CI — this page covers the mechanical upgrade: the image, the moved commands, and the reworked review-environment calls.

Moving those workflows onto codev entirely — so the server runs them and there is no image or command for you to maintain — is a separate, gradual path; see Migrating to codev. The steps below apply to any sfp calls you still run yourself during or after that move.

Step 1 — Update the image

Point the version tag your pipeline pulls at a v51 release.

# Before (v50)
container:
  image: source.flxbl.io/flxbl/sfp-pro:50.x

# After (v51)
container:
  image: source.flxbl.io/flxbl/sfp-pro:51.x

If you mirror the image into your own registry, sync the v51 tag first — see Automated Image Synchronization to Your Registry. Valid version tags are listed at https://source.flxbl.io/flxbl/-/packages/container/sfp-pro/.

What comes with the new image:

You no longer install sfdmu yourself. On v50 the image ran sf plugins:install sfdmu; on v51 the data-move runtime ships inside the image and sfp calls it directly — remove any sf plugins:install sfdmu step from custom images. If you extend the sfp-pro base image with your own apt-get install layer, note that the trixie transition renames some system packages (the t64 suffix, e.g. libasound2 → libasound2t64).

Step 2 — Rename the moved commands

Most v50 commands run unchanged on v51. Commands that moved under a parent topic keep a backward-compatible alias, so existing invocations still resolve. The one exception is releasedefinition:generate: it was removed with no alias, and release definitions are now generated by sfp releasecandidate generate, which publishes them to the server as release candidates. Update it wherever your pipeline calls it.

# Before (v50)
sfp releasedefinition:generate -c HEAD -d release-definitions -f release-configs/my-release.yml -n $RELEASE_NAME -b $RELEASE_BRANCH

# After (v51)
sfp releasecandidate generate -c HEAD -f release-configs/my-release.yml -n $RELEASE_NAME -b $RELEASE_BRANCH --repository $GITHUB_REPOSITORY

The flags that wrote the definition to disk — -d, --directory, --branchname, --nopush, --forcepush — do not exist on the new command. -b, --branch also changed meaning: it records the branch against the release candidate rather than naming a branch to commit the definition into. To keep writing a file, add --nopublish --output <path>; to publish and keep a copy on disk, follow the generate with sfp releasecandidate fetch -o <path>. See Generating a release definition.

Moved but still work via aliases (update at your own pace):

Commands that did not move: sfp build, sfp install, sfp publish, sfp release, sfp pool delete, sfp validate pool. Your existing flags on these are unchanged.

A few v50 topics were removed entirely because the server owns them now (ai, config, resource, and the top-level releasedefinition). If your pipeline manually queued environment locks with sfp resource enqueue / wait / dequeue, that is replaced in Step 3.

Step 3 — Rework review-environment calls

This is the largest change for pipelines that run PR validation. On v50, fetching a review org, holding an exclusive lock, and returning it were separate CLI calls. On v51 the server manages the lease, and the CLI reserves and acquires in two phases.

# Before (v50) — one fetch, one status flip to return it
sfp reviewenv fetch --repository "$REPO" --issue "$PR" --pool "$POOL" --pooltype "$TYPE" --leasefor 60
# ... run validation ...
sfp reviewenv transition --repository "$REPO" --issue "$PR" --status "Available"

# After (v51) — reserve, then acquire exclusive access; release when done
sfp server review-envs assign  --type pr --id "$PR" --repository "$REPO" --pool-tag "$POOL_TAG" --domain "$DOMAIN" --expiration 60 --json
sfp server review-envs acquire --type pr --id "$PR" --repository "$REPO" --domain "$DOMAIN" --duration 90 --wait --poll-interval 30 --json
# ... run validation ...
sfp server review-envs release --type pr --id "$PR" --repository "$REPO"

Two related simplifications come with this:

• Pool-type probing is gone. v50 ran sfp pool probe to discover a pool's type before fetching. v51 carries the pool by tag, so that step is removed.
• Environment locking is a single action. The manual sfp resource enqueue / wait / dequeue sequence is replaced by one lock-and-authenticate step.

Step 4 — Verify

Confirm the CLI is on v51:

$ sfp --version
@flxbl-io/sfp-pro/51.23.0 darwin-arm64 node-v26.4.0

From here, each capability you hand to the server — build-on-merge, validation, pools — retires its CLI step from your pipeline. Migrating to codev walks that handover.