GitHub Actions
The sfpm GitHub Actions, how to reference them, and what the runner must provide.
The sfpm GitHub Actions are thin wrappers around the same orchestrators the CLI uses. Each action reads its inputs, runs one flow (build, validate, install, deploy, or pool management), and sets outputs your workflow can read.
The actions do not install their own prerequisites and do not handle credentials. Your workflow sets up the Salesforce CLI and authenticates the DevHub and target orgs before the sfpm step runs.
sfpm is pre-1.0. Action inputs, outputs, and defaults may change between releases.
Referencing an action
The actions live under packages/actions/ in the sfpm repository. Reference them by sub-path:
- uses: b64hub/sfpm/packages/actions/build@vX.Y.Z
- uses: b64hub/sfpm/packages/actions/validate-pr@vX.Y.ZReplace vX.Y.Z with a release tag from the sfpm releases page. The same path works with the moving v0 tag and with commit SHAs. See Versioning and pinning for when to use each form.
Each release tag points to a commit that contains the action bundle. The bundle is not on main. A reference to main or to any other commit will fail to run.
Available actions
| Action | Purpose |
|---|---|
build | Builds packages in dependency order and returns a result JSON for build-validation. Unlocked packages are meant to create package versions asynchronously at org/full validation, but see the known DevHub-wiring limitation in Build, validate, publish before relying on that at the default settings. |
build-validation | Resolves pending async validation from a build result. Outputs publishable-packages, the list of packages that are safe to publish. |
build-turbo-aggregate | Reads the output of a turbo run build and produces the same result shape as build, so build-validation can consume it. |
install | Installs packages into a target org. Resolves packages from the npm registry (origin: registry, the default) or from dist/ output already on disk (origin: local). |
deploy | Installs published artifacts from the npm registry by source deploy. It performs the same kind of operation as sfpm deploy artifact, but the two are not identical: inputs, defaults such as force, and lifecycle stage differ. Check the action's action.yml rather than assuming CLI parity. It is not the CLI's sfpm deploy, which deploys from local source. |
validate-pr | Validates a pull request with local nimbus checks (mode: local, the default) or by deploying to an org from a scratch org pool (mode: org). |
fill-pool | Provisions scratch orgs or sandboxes for one or more pool tags. |
clean-pool | Deletes orgs from a scratch org or sandbox pool. |
Each action's action.yml lists its full inputs and outputs. The packages/actions/examples/ directory in the sfpm repository has example workflows.
What the runner must provide
| Requirement | Notes |
|---|---|
| Node 24 runtime | Provided by the GitHub Actions runner (v2.327.1 or later). The actions declare runs.using: node24, so you do not need actions/setup-node for them. Self-hosted and GHES runners must support Node 24. |
sf CLI on PATH | Required on the runner. Your steps use it for org authentication. |
| DevHub and target orgs authenticated | Done in your workflow before the sfpm step. The actions never receive or store org credentials. |
npm on PATH | Required by install with origin: registry, and by deploy, which always resolves from the registry. |
| nimbus on PATH | Required for local validation. Without it, validate-pr in local mode reports that nimbus is missing: the compile check is marked skipped and the dependency check reports an error. |
| Git checkout | The actions read the project from GITHUB_WORKSPACE by default. validate-pr also needs full git history for changed-package detection. See Validating pull requests. |
GitHub-hosted runners already provide the Node runtime the actions need, so you do not install Node for the actions. If a workflow step installs the sfpm or Salesforce CLI directly, check the installation page for the Node.js version that package declares.
Next steps
Versioning and pinning
Pin a release tag, a moving major tag, or a commit SHA.
Security and network
Token permissions, credential handling, and network egress.
Build, validate, publish
A CI workflow that builds, validates, and publishes packages.
Validate pull requests
Local and org-backed validation for pull requests.