project deploy validate

Validate a metadata deployment without actually executing it.

Use this command to verify whether a deployment will succeed without actually deploying the metadata to your org. This command is similar to “sf project deploy start”, except you’re required to run Apex tests, and the command returns a job ID rather than executing the deployment. If the validation succeeds, then you pass this job ID to the “sf project deploy quick” command to actually deploy the metadata. This quick deploy takes less time because it skips running Apex tests. The job ID is valid for 10 days from when you started the validation. Validating first is useful if the deployment to your production org take several hours and you don’t want to risk a failed deploy.

You must run this command from within a project.

This command doesn’t support source-tracking. When you quick deploy with the resulting job ID, the source you deploy overwrites the corresponding metadata in your org.

To validate the deployment of multiple metadata components, either set multiple –metadata <name> flags or a single –metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax applies to –source-dir.

Note: Don’t use this command on sandboxes; the command is intended to be used on production orgs. By default, sandboxes don’t run tests during a deploy. If you want to validate a deployment with tests on a sandbox, use “sf project deploy start –dry-run –test-level RunLocalTests” instead.

deploy:metadata:validate

Flag Name (Long)Flag Name (Short)Description
‑‑api‑version‑aType: Value

Target API version for the validation.

Use this flag to override the default API version with the API version of your package.xml file. The default API version is the latest version supported by the CLI.
‑‑asyncN/AType: Boolean

Run the command asynchronously.

The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the CLI. To resume watching the validation, run “sf project deploy resume”. To check the status of the validation, run “sf project deploy report”.
‑‑conciseN/AType: Boolean

Show concise output of the validation result.
‑‑coverage‑formattersN/AType: Value
Valid Values: clover, cobertura, html-spa, html, json, json-summary, lcovonly, none, teamcity, text, text-summary

Format of the code coverage results.

For multiple formatters, repeat the flag for each formatter.

–coverage-formatters lcov –coverage-formatters clover
‑‑flags‑dirN/AType: Value

Import flag values from a directory.
‑‑ignore‑warnings‑gType: Boolean

Ignore warnings and allow a deployment to complete successfully.

If you specify this flag, and a warning occurs, the success status of the deployment is set to true. If you don’t specify this flag, and a warning occurs, then the success status is set to false, and the warning is treated like an error.

This flag is useful in a CI environment and your deployment includes destructive changes; if you try to delete a component that doesn’t exist in the org, you get a warning. In this case, to ensure that the command returns a success value of true, specify this flag.
‑‑jsonN/AType: Boolean

Format output as json.
‑‑junitN/AType: Boolean

Output JUnit test results.
‑‑manifest‑xType: Value

Full file path for manifest (package.xml) of components to validate for deployment.

All child components are included. If you specify this flag, don’t specify –metadata or –source-dir.
‑‑metadata‑mType: Value

Metadata component names to validate for deployment.
‑‑metadata‑dirN/AType: Value

Root of directory or zip file of metadata formatted files to deploy.
‑‑post‑destructive‑changesN/AType: Value

File path for a manifest (destructiveChangesPost.xml) of components to delete after the deploy.
‑‑pre‑destructive‑changesN/AType: Value

File path for a manifest (destructiveChangesPre.xml) of components to delete before the deploy
‑‑purge‑on‑deleteN/AType: Boolean

Specify that deleted components in the destructive changes manifest file are immediately eligible for deletion rather than being stored in the Recycle Bin.
‑‑results‑dirN/AType: Value

Output directory for code coverage and JUnit results; defaults to the deploy ID.
‑‑single‑packageN/AType: Boolean

Indicates that the metadata zip file points to a directory structure for a single package.
‑‑source‑dir‑dType: Value

Path to the local source files to validate for deployment.

The supplied path can be to a single file (in which case the operation is applied to only one file) or to a folder (in which case the operation is applied to all metadata types in the directory and its subdirectories).

If you specify this flag, don’t specify –metadata or –manifest.
‑‑target‑org‑oType: Value
Required

Username or alias of the target org. Not required if the target-org configuration variable is already set.
‑‑test‑level‑lType: Value
Valid Values: RunAllTestsInOrg, RunLocalTests, RunSpecifiedTests, RunRelevantTests
Default value: RunLocalTests

Deployment Apex testing level.

Valid values are:

  • RunSpecifiedTests — Runs only the tests that you specify with the –tests flag. Code coverage requirements differ from the default coverage requirements when using this test level. Executed tests must comprise a minimum of 75% code coverage for each class and trigger in the deployment package. This coverage is computed for each class and trigger individually and is different than the overall coverage percentage.
  • RunLocalTests — All tests in your org are run, except the ones that originate from installed managed and unlocked packages. This test level is the default.
  • RunAllTestsInOrg — All tests in your org are run, including tests of managed packages.
  • RunRelevantTests (Beta) — Runs only tests that are relevant to the files being deployed. Salesforce automatically identifies the relevant tests based on an analysis of the deployment payload and the payload dependencies. For fine-grained control, you can also annotate test classes so that they always run in certain conditions. See “@IsTest Annotation” in the “Apex Developer Guide” (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_annotation_isTest.htm). Each class and trigger in the deployment package must be covered by the executed tests for a minimum of 75% code coverage. This coverage is computed for each class and triggers individually and is different than the overall coverage percentage.


If you don’t specify a test level, the default behavior depends on the contents of your deployment package and target org. For more information, see “Running Tests in a Deployment” (https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_running_tests.htm) in the “Metadata API Developer Guide”.
‑‑tests‑tType: Value

Apex tests to run when –test-level is RunSpecifiedTests.

If a test name contains a space, enclose it in double quotes.

For multiple test names, use one of the following formats:

  • Repeat the flag for multiple test names: –tests Test1 –tests Test2 –tests “Test With Space”
  • Separate the test names with spaces: –tests Test1 Test2 “Test With Space”
‑‑verboseN/AType: Boolean

Show verbose output of the validation result.
‑‑wait‑wType: Value
Default value: 33 minutes

Number of minutes to wait for the command to complete and display results.

If the command continues to run after the wait period, the CLI returns control of the terminal window to you and returns the job ID. To resume watching the validation, run “sf project deploy resume”. To check the status of the validation, run “sf project deploy report”.

Validate the deployment of all source files in the “force-app” directory to the default org:

Validate the deployment of all source files in two directories: “force-app” and “force-app-utils”:

Asynchronously validate the deployment and run all tests in the org with alias “my-prod-org”; command immediately returns the job ID:

Validate the deployment of all components listed in a manifest: