Use this action to build a package.xml (or use your own) and deploy to a specified Salesforce environment. After deployment, it writes a job summary on the Actions run (including metrics, component changes—name, type, and create/change/delete/unchanged/failed—and optional failure details) and exposes outputs for downstream steps.

DRY_RUN:
 description: "Validate deploy and run Apex tests but don't save to the org."
 type: boolean
TEST_LEVEL:
 description: "Deployment Apex testing level."
 type: choice
 default: "RunLocalTests"
 options:
 - NoTestRun
 - RunSpecifiedTests
 - RunLocalTests
 - RunAllTestsInOrg
 - RunRelevantTests
WAIT:
 description: "Number of minutes to wait for command to complete and display results."
 type: number
 default: 30
SOURCE_DIRECTORY:
 description: "Path to the local source files to deploy (used only when MANIFEST_PATH is not set)."
 type: string
 default: "force-app"
MANIFEST_PATH:
 description: "If set, deploy this manifest instead of generating one from SOURCE_DIRECTORY."
 type: string
POST_DESTRUCTIVE_CHANGES:
 description: "If set, passed to sf project deploy start as --post-destructive-changes."
 type: string
SFDX_AUTH_URL:
 description: "The auth url tied to your deployment environment"
 type: string
 required: true
DEPLOYMENT_ID:
 description: "The deployment id from a validation/ dry run."
 type: string

Coverage is derived from runTestResult.codeCoverage in the deploy result. It is a lines-hit / lines-total rollup across returned rows, not the same as every Salesforce UI metric.

The summary includes a Component changes table built from the deploy result’s componentSuccesses and componentFailures:

The manifest artifact row package.xml is omitted. Large deploys list at most 500 rows, with a note if more exist.

This action does not run sfdx-git-delta. In your workflow, install the plugin, run sf sgd source delta, then pass the generated paths into this action.

• Use MANIFEST_PATH for the incremental package.xml (for example sgd-out/package/package.xml).
• Set POST_DESTRUCTIVE_CHANGES when you also want post-destructive deletes in the same deploy (for example sgd-out/destructiveChanges/destructiveChanges.xml). Omit it when that file does not exist or you are not deleting metadata.
• For comparisons against origin/main (or similar), use actions/checkout with enough history (for example fetch-depth: 0) so git can resolve both refs.
• Avoid deploying an empty package.xml; follow SGD’s guidance and branch in your workflow when there is nothing to deploy.

Example fragment (same job must have the Salesforce CLI available before SGD):

- name: Install Salesforce CLI
 run: npm install -g @salesforce/cli
- name: Install SGD
 run: echo y | sf plugins install sfdx-git-delta
- name: Delta manifest
 run: sf sgd source delta --from "origin/main" --to "HEAD" --output-dir sgd-out --source-dir force-app
- name: Deploy
 uses: your-org/github-actions@main
 with:
 SFDX_AUTH_URL: ${{ secrets.SFDX_AUTH_URL }}
 MANIFEST_PATH: sgd-out/package/package.xml
 POST_DESTRUCTIVE_CHANGES: sgd-out/destructiveChanges/destructiveChanges.xml

(Adjust the action reference and wire POST_DESTRUCTIVE_CHANGES only when that file exists, for example with a conditional step or if: in your workflow.)

To get the SFDX_AUTH_URL, enter the following command in your terminal:

sf org display --verbose --json -o <MY_TARGET_ORG_ALIAS>

Copy down the value of sfdxAuthUrl for later.

You can see how these work by checking my write-up or YouTube video.