For the complete documentation index, see llms.txt. This page is also available as Markdown.

Upgrading the CLI from v50 to v51

Upgrading a self-run sfp-pro pipeline from v50 to v51 — bump the image, rename the handful of moved commands, and rework review-environment calls against sfp server.

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:

Component
v50
v51

Base OS

Debian bookworm

Debian trixie

Salesforce CLI

2.131.7

2.135.7

JDK

17

21

Data-move runtime (sfdmu)

installed as an sf plugin

bundled in the image, invoked in-process

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. libasound2libasound2t64).

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 moved under sfp server with no alias, so update it wherever your pipeline calls it.

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

v50
v51 canonical
Old form still works?

sfp dependency install

sfp org dependency install

Yes (alias)

sfp pool prepare

sfp server pool scratch init

Yes (alias)

sfp reviewenv fetch / transition

sfp server review-envs assign / acquire / release

No — reworked, see Step 3

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.

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:

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.

sfp versioning and upgrade Process

Last updated

Was this helpful?