@salesforce/plugin-deploy-retrieve

v3.16.4

Published

2 days ago

deploy and retrieve commands for sf

Downloads

664,057

plugin-deploy-retrieve

Install

sf plugins:install [email protected]

Contributing

Please read our Code of Conduct
Create a new issue before starting your project so that we can keep track of what you are trying to add/fix. That way, we can also offer suggestions or let you know if there is already an effort in progress.
Fork this repository.
Build the plugin locally
Create a topic branch in your fork. Note, this step is recommended but technically not required if contributing using a fork.
Edit the code in your fork.
Write appropriate tests for your changes. Try to achieve at least 95% code coverage on any new code. No pull request will be accepted without unit tests.
Sign CLA (see CLA below).
Send us a pull request when you are done. We'll review your code, suggest any needed changes, and merge it in.

CLA

External contributors will be required to sign a Contributor's License Agreement. You can do so by going to https://cla.salesforce.com/sign-cla.

Build

To build the plugin locally, make sure to have yarn installed and run the following commands:

# Clone the repository
git clone [email protected]:salesforcecli/plugin-deploy-retrieve

# Install the dependencies and compile
yarn install
yarn build

To use your plugin, run using the local ./bin/dev.js or ./bin/dev.cmd file.

# Run using local run file.
./bin/dev.js deploy

There should be no differences when running via the Salesforce CLI or using the local run file. However, it can be useful to link the plugin to do some additional testing or run your commands from anywhere on your machine.

# Link your plugin to the sf cli
sf plugins:link .
# To verify
sf plugins

Commands

`sf project convert mdapi`

Convert metadata retrieved via Metadata API into the source format used in Salesforce DX projects.

USAGE
  $ sf project convert mdapi -r <value> [--json] [--flags-dir <value>] [--api-version <value>] [-d <value>] [-p <value>...
    | -x <value> | -m <value>...]

FLAGS
  -d, --output-dir=<value>       Directory to store your files in after they’re converted to source format; can be an
                                 absolute or relative path.
  -m, --metadata=<value>...      Metadata component names to convert.
  -p, --metadata-dir=<value>...  Root of directory or zip file of metadata formatted files to convert.
  -r, --root-dir=<value>         (required) Root directory that contains the Metadata API–formatted metadata.
  -x, --manifest=<value>         File path to manifest (package.xml) of metadata types to convert.
      --api-version=<value>      Override the api version used for api requests made by this command

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Convert metadata retrieved via Metadata API into the source format used in Salesforce DX projects.

  To use Salesforce CLI to work with components that you retrieved via Metadata API, first convert your files from the
  metadata format to the source format using this command.

  To convert files from the source format back to the metadata format, run "sf project convert source".

  To convert 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.

ALIASES
  $ sf force mdapi convert

EXAMPLES
  Convert metadata formatted files in the specified directory into source formatted files; writes converted files to
  your default package directory:

    $ sf project convert mdapi --root-dir path/to/metadata

  Similar to previous example, but writes converted files to the specified output directory:

    $ sf project convert mdapi --root-dir path/to/metadata --output-dir path/to/outputdir

FLAG DESCRIPTIONS
  -p, --metadata-dir=<value>...  Root of directory or zip file of metadata formatted files to convert.

    The supplied paths 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 sub-directories).

    If you specify this flag, don’t specify --manifest or --metadata. If the comma-separated list you’re supplying
    contains spaces, enclose the entire comma-separated list in one set of double quotes.

  -x, --manifest=<value>  File path to manifest (package.xml) of metadata types to convert.

    If you specify this flag, don’t specify --metadata or --source-dir.

See code: src/commands/project/convert/mdapi.ts

`sf project convert source`

Convert source-formatted files into metadata that you can deploy using Metadata API.

USAGE
  $ sf project convert source [--json] [--flags-dir <value>] [--api-version <value>] [-r <value>] [-d <value>] [-n <value>]
    [-p <value>... | -x <value> | -m <value>...]

FLAGS
  -d, --output-dir=<value>     [default: metadataPackage_>timestamp<] Output directory to store the Metadata
                               API–formatted files in.
  -m, --metadata=<value>...    Metadata component names to convert.
  -n, --package-name=<value>   Name of the package to associate with the metadata-formatted files.
  -p, --source-dir=<value>...  Paths to the local source files to convert.
  -r, --root-dir=<value>       Source directory other than the default package to convert.
  -x, --manifest=<value>       Path to the manifest (package.xml) file that specifies the metadata types to convert.
      --api-version=<value>    API Version to use in the generated project's manifest. By default, will use the version
                               from sfdx-project.json

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Convert source-formatted files into metadata that you can deploy using Metadata API.

  To convert source-formatted files into the metadata format, so that you can deploy them using Metadata API, run this
  command. Then deploy the metadata using "sf project deploy".

  To convert Metadata API–formatted files into the source format, run "sf project convert mdapi".

  To specify a package name that includes spaces, enclose the name in single quotes.

  To convert multiple 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.

ALIASES
  $ sf force source convert

EXAMPLES
  Convert source-formatted files in the specified directory into metadata-formatted files; writes converted files into
  a new directory:

    $ sf project convert source --root-dir path/to/source

  Similar to previous example, but writes converted files to the specified output directory and associates the files
  with the specified package:

    $ sf project convert source --root-dir path/to/source --output-dir path/to/outputdir --package-name 'My Package'

FLAG DESCRIPTIONS
  -p, --source-dir=<value>...  Paths to the local source files to convert.

    The supplied paths 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 sub-directories).

    If you specify this flag, don’t specify --manifest or --metadata.

  -x, --manifest=<value>  Path to the manifest (package.xml) file that specifies the metadata types to convert.

    If you specify this flag, don’t specify --metadata or --source-dir.

  --api-version=<value>

    API Version to use in the generated project's manifest. By default, will use the version from sfdx-project.json

    Override the api version used for api requests made by this command

See code: src/commands/project/convert/source.ts

`sf project convert source-behavior`

Enable a behavior of your project source files, and then update your Salesforce DX project to implement the behavior.

USAGE
  $ sf project convert source-behavior -b
    decomposeCustomLabelsBeta2|decomposeCustomLabelsBeta|decomposePermissionSetBeta|decomposePermissionSetBeta2|decompos
    eSharingRulesBeta|decomposeWorkflowBeta [--json] [--flags-dir <value>] [--dry-run] [--preserve-temp-dir] [-o
    <value>]

FLAGS
  -b, --behavior=<option>   (required) Behavior to enable; the values correspond to the possible values of the
                            "sourceBehaviorOption" option in the "sfdx-project.json" file.
                            <options: decomposeCustomLabelsBeta2|decomposeCustomLabelsBeta|decomposePermissionSetBeta|de
                            composePermissionSetBeta2|decomposeSharingRulesBeta|decomposeWorkflowBeta>
  -o, --target-org=<value>  Username or alias of the target org.
      --dry-run             Display what the command would do, but don't make any actual changes.
      --preserve-temp-dir   Don't delete the metadata API format temporary directory that this command creates. Useful
                            for debugging.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Enable a behavior of your project source files, and then update your Salesforce DX project to implement the behavior.

  Specifically, this command updates the "sourceBehaviorOption" option in the "sfdx-project.json" file and then converts
  the associated local source files in your project as needed.

  For example, run this command with the "--behavior decomposePermissionSetBeta" flag to start decomposing permission
  sets when you deploy or retrieve them. Decomposing means breaking up the monolithic metadata API format XML file that
  corresponds to a metadata component into smaller XML files and directories based on its subtypes. Permission sets are
  not decomposed by default; you must opt-in to start decomposing them by using this command. When the command finishes,
  your "sfdx-project.json" file is updated to always decompose permission sets, and the existing permission set files in
  your local package directories are converted into the new decomposed format. You run this command only once for a
  given behavior change.

  For more information about the possible values for the --behavior flag, see the "sourceBehaviorOptions" section in the
  https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_config.htm topic.

EXAMPLES
  Update your Salesforce DX project to decompose custom permission sets:

    $ sf project convert source-behavior --behavior decomposePermissionSetBeta

  Display what the command would do, but don't change any existing files:

    $ sf project convert source-behavior --behavior decomposePermissionSetBeta --dry-run

  Keep the temporary directory that contains the interim metadata API formatted files:

    $ sf project convert source-behavior --behavior decomposePermissionSetBeta --dry-run --preserve-temp-dir

See code: src/commands/project/convert/source-behavior.ts

`sf project delete source`

Delete source from your project and from a non-source-tracked org.

USAGE
  $ sf project delete source -o <value> [--json] [--flags-dir <value>] [--api-version <value>] [-w <value>] [--tests
    <value>...] [-l NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg] [-r] [-m <value>...] [-p <value>...] [-f
    [-t | -c]] [--verbose]

FLAGS
  -c, --check-only             Validate delete command but don't delete anything from the org or the local project.
  -f, --force-overwrite        Ignore conflict warnings and overwrite changes to the org.
  -m, --metadata=<value>...    Metadata components to delete.
  -o, --target-org=<value>     (required) Username or alias of the target org. Not required if the `target-org`
                               configuration variable is already set.
  -p, --source-dir=<value>...  Source file paths to delete.
  -r, --no-prompt              Don't prompt for delete confirmation.
  -t, --track-source           If the delete succeeds, update the source tracking information.
  -w, --wait=<value>           Number of minutes to wait for the command to finish.
      --api-version=<value>    Override the api version used for api requests made by this command
      --verbose                Verbose output of the delete result.

TEST FLAGS
  -l, --test-level=<option>  Deployment Apex testing level.
                             <options: NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg>
      --tests=<value>...     Apex tests to run when --test-level is RunSpecifiedTests.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Delete source from your project and from a non-source-tracked org.

  Use this command to delete components from orgs that don’t have source tracking. To remove deleted items from orgs
  that have source tracking enabled, "sf project deploy start".

  When you run this command, both the local source file and the metadata component in the org are deleted.

  To delete 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.

ALIASES
  $ sf force source delete

EXAMPLES
  Delete all local Apex source files and all Apex classes from the org with alias "my-scratch":

    $ sf project delete source --metadata ApexClass --target-org my-scratch

  Delete a specific Apex class and a Profile that has a space in it from your default org; don't prompt for
  confirmation:

    $ sf project delete source --metadata ApexClass:MyFabulousApexClass --metadata "Profile: My Profile" --no-prompt

  Run the tests that aren’t in any managed packages as part of the deletion; if the delete succeeds, and the org has
  source-tracking enabled, update the source tracking information:

    $ sf project delete source --metadata ApexClass --test-level RunLocalTests --track-source

  Delete the Apex source files in a directory and the corresponding components from your default org:

    $ sf project delete source --source-dir force-app/main/default/classes

FLAG DESCRIPTIONS
  -c, --check-only  Validate delete command but don't delete anything from the org or the local project.

    IMPORTANT: Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained
    certain terms to avoid any effect on customer implementations.

    Validates the deleted metadata and runs all Apex tests, but prevents the deletion from being saved to the org.

    If you change a field type from Master-Detail to Lookup or vice versa, that change isn’t supported when using the
    --check-only flag to test a deletion (validation). This kind of change isn’t supported for test deletions to avoid
    the risk of data loss or corruption. If a change that isn’t supported for test deletions is included in a deletion
    package, the test deletion fails and issues an error.

    If your deletion package changes a field type from Master-Detail to Lookup or vice versa, you can still validate the
    changes prior to deploying to Production by performing a full deletion to another test Sandbox. A full deletion
    includes a validation of the changes as part of the deletion process.

    Note: A Metadata API deletion that includes Master-Detail relationships deletes all detail records in the Recycle
    Bin in the following cases.

    1. For a deletion with a new Master-Detail field, soft delete (send to the Recycle Bin) all detail records before
    proceeding to delete the Master-Detail field, or the deletion fails. During the deletion, detail records are
    permanently deleted from the Recycle Bin and cannot be recovered.

    2. For a deletion that converts a Lookup field relationship to a Master-Detail relationship, detail records must
    reference a master record or be soft-deleted (sent to the Recycle Bin) for the deletion to succeed. However, a
    successful deletion permanently deletes any detail records in the Recycle Bin.

  -l, --test-level=NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg  Deployment Apex testing level.

    Valid values are:

    - NoTestRun — No tests are run. This test level applies only to deployments to development environments, such as
    sandbox, Developer Edition, or trial orgs. This test level is the default for development environments.

    - 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 for production deployments that include Apex classes or triggers.

    - RunAllTestsInOrg — All tests in your org are run, including tests of managed packages.

    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” in the Metadata API Developer Guide.

  -m, --metadata=<value>...  Metadata components to delete.

    If you specify this flag, don’t specify --source-dir.

  -p, --source-dir=<value>...  Source file paths to delete.

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

    If you specify this flag, don’t specify --metadata.

  -w, --wait=<value>  Number of minutes to wait for the command to finish.

    If the command continues to run after the wait period, the CLI returns control of the terminal window to you.

  --tests=<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"

See code: src/commands/project/delete/source.ts

`sf project delete tracking`

Delete all local source tracking information.

USAGE
  $ sf project delete tracking -o <value> [--json] [--flags-dir <value>] [--api-version <value>] [-p]

FLAGS
  -o, --target-org=<value>   (required) Username or alias of the target org. Not required if the `target-org`
                             configuration variable is already set.
  -p, --no-prompt            Don't prompt for source tracking override confirmation.
      --api-version=<value>  Override the api version used for api requests made by this command

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Delete all local source tracking information.

  WARNING: This command deletes or overwrites all existing source tracking files. Use with extreme caution.

  Deletes all local source tracking information. When you next run 'project deploy preview', Salesforce CLI displays all
  local and remote files as changed, and any files with the same name are listed as conflicts.

ALIASES
  $ sf force source tracking clear

EXAMPLES
  Delete local source tracking for the org with alias "my-scratch":

    $ sf project delete tracking --target-org my-scratch

See code: src/commands/project/delete/tracking.ts

`sf project deploy cancel`

Cancel a deploy operation.

USAGE
  $ sf project deploy cancel [--json] [--flags-dir <value>] [-o <value>] [--async | -w <minutes>] [-i <value>] [-r]

FLAGS
  -i, --job-id=<value>      Job ID of the deploy operation you want to cancel.
  -o, --target-org=<value>  Username or alias of the target org.
  -r, --use-most-recent     Use the job ID of the most recent deploy operation.
  -w, --wait=<minutes>      Number of minutes to wait for the command to complete and display results.
      --async               Run the command asynchronously.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Cancel a deploy operation.

  Use this command to cancel a deploy operation that hasn't yet completed in the org. Deploy operations include standard
  deploys, quick deploys, deploy validations, and deploy cancellations.

  Run this command by either passing it a job ID or specifying the --use-most-recent flag to use the job ID of the most
  recent deploy operation.

ALIASES
  $ sf deploy metadata cancel

EXAMPLES
  Cancel a deploy operation using a job ID:

    $ sf project deploy cancel --job-id 0Af0x000017yLUFCA2

  Cancel the most recent deploy operation:

    $ sf project deploy cancel --use-most-recent

FLAG DESCRIPTIONS
  -i, --job-id=<value>  Job ID of the deploy operation you want to cancel.

    These commands return a job ID if they time out or you specified the --async flag:

    - sf project deploy start
    - sf project deploy validate
    - sf project deploy quick
    - sf project deploy cancel

    The job ID is valid for 10 days from when you started the deploy operation.

  -r, --use-most-recent  Use the job ID of the most recent deploy operation.

    For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less.
    If your most recent deploy operations was more than 3 days ago, this flag won't find a job ID.

  -w, --wait=<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. To
    resume watching the cancellation, run "sf project deploy resume". To check the status of the cancellation, run "sf
    project deploy report".

  --async  Run the command asynchronously.

    The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To
    resume watching the cancellation, run "sf project deploy resume". To check the status of the cancellation, run "sf
    project deploy report".

See code: src/commands/project/deploy/cancel.ts

`sf project deploy preview`

Preview a deployment to see what will deploy to the org, the potential conflicts, and the ignored files.

USAGE
  $ sf project deploy preview -o <value> [--json] [--flags-dir <value>] [-c] [-x <value> | -d <value>... | -m <value>...]
    [--concise]

FLAGS
  -c, --ignore-conflicts       Don't display conflicts in preview of the deployment.
  -d, --source-dir=<value>...  Path to the local source files to preview.
  -m, --metadata=<value>...    Metadata component names to preview.
  -o, --target-org=<value>     (required) Username or alias of the target org. Not required if the `target-org`
                               configuration variable is already set.
  -x, --manifest=<value>       Full file path for manifest (package.xml) of components to preview.
      --concise                Show only the changes that will be deployed; omits files that are forceignored.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Preview a deployment to see what will deploy to the org, the potential conflicts, and the ignored files.

  You must run this command from within a project.

  The command outputs a table that describes what will happen if you run the "sf project deploy start" command. The
  table lists the metadata components that will be deployed and deleted. The table also lists the current conflicts
  between files in your local project and components in the org. Finally, the table lists the files that won't be
  deployed because they're included in your .forceignore file.

  If your org allows source tracking, then this command displays potential conflicts between the org and your local
  project. Some orgs, such as production org, never allow source tracking. Source tracking is enabled by default on
  scratch and sandbox orgs; you can disable source tracking when you create the orgs by specifying the --no-track-source
  flag on the "sf org create scratch|sandbox" commands.

  To preview 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.

ALIASES
  $ sf deploy metadata preview

EXAMPLES
  NOTE: The commands to preview a deployment and actually deploy it use similar flags. We provide a few preview examples here, but see the help for "sf project deploy start" for more examples that you can adapt for previewing.

  Preview the deployment of source files in a directory, such as force-app, to your default org:

    $ sf project deploy preview  --source-dir force-app

  Preview the deployment of all Apex classes to an org with alias "my-scratch":

    $ sf project deploy preview --metadata ApexClass --target-org my-scratch

  Preview deployment of a specific Apex class:

    $ sf project deploy preview --metadata ApexClass:MyApexClass

  Preview deployment of all components listed in a manifest:

    $ sf project deploy preview --manifest path/to/package.xml

FLAG DESCRIPTIONS
  -c, --ignore-conflicts  Don't display conflicts in preview of the deployment.

    This flag applies only to orgs that allow source tracking. It has no effect on orgs that don't allow it, such as
    production orgs.

  -d, --source-dir=<value>...  Path to the local source files to preview.

    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.

  -x, --manifest=<value>  Full file path for manifest (package.xml) of components to preview.

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

See code: src/commands/project/deploy/preview.ts

`sf project deploy quick`

Quickly deploy a validated deployment to an org.

USAGE
  $ sf project deploy quick [--json] [--flags-dir <value>] [--async | -w <minutes>] [--concise | --verbose] [-i <value>]
    [-o <value>] [-r] [-a <value>]

FLAGS
  -a, --api-version=<value>  Target API version for the deploy.
  -i, --job-id=<value>       Job ID of the deployment you want to quick deploy.
  -o, --target-org=<value>   Username or alias of the target org.
  -r, --use-most-recent      Use the job ID of the most recently validated deployment.
  -w, --wait=<minutes>       [default: 33 minutes] Number of minutes to wait for the command to complete and display
                             results.
      --async                Run the command asynchronously.
      --concise              Show concise output of the deploy result.
      --verbose              Show verbose output of the deploy result.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Quickly deploy a validated deployment to an org.

  Before you run this command, first create a validated deployment with the "sf project deploy validate" command, which
  returns a job ID. Validated deployments haven't been deployed to the org yet; you deploy them with this command.
  Either pass the job ID to this command or use the --use-most-recent flag to use the job ID of the most recently
  validated deployment. For the quick deploy to succeed, the associated validated deployment must also have succeeded.

  Executing this quick deploy command takes less time than a standard deploy because it skips running Apex tests. These
  tests were previously run as part of the validation. Validating first and then running a quick deploy is useful if the
  deployment to your production org take several hours and you don’t want to risk a failed deploy.

  This command doesn't support source-tracking. The source you deploy overwrites the corresponding metadata in your org.
  This command doesn’t attempt to merge your source with the versions in your org.

  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. Use "sf project deploy start" instead.

ALIASES
  $ sf deploy metadata quick

EXAMPLES
  Run a quick deploy to your default org using a job ID:

    $ sf project deploy quick --job-id 0Af0x000017yLUFCA2

  Asynchronously run a quick deploy of the most recently validated deployment to an org with alias "my-prod-org":

    $ sf project deploy quick --async --use-most-recent --target-org my-prod-org

FLAG DESCRIPTIONS
  -a, --api-version=<value>  Target API version for the deploy.

    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.

  -i, --job-id=<value>  Job ID of the deployment you want to quick deploy.

    The job ID is valid for 10 days from when you started the validation.

  -r, --use-most-recent  Use the job ID of the most recently validated deployment.

    For performance reasons, this flag uses only job IDs that were validated in the past 3 days or less. If your most
    recent deployment validation was more than 3 days ago, this flag won't find a job ID.

  -w, --wait=<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. To
    resume watching the deploy, run "sf project deploy resume". To check the status of the deploy, run "sf project
    deploy report".

  --async  Run the command asynchronously.

    The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To
    resume watching the deploy, run "sf project deploy resume". To check the status of the deploy, run "sf project
    deploy report".

See code: src/commands/project/deploy/quick.ts

`sf project deploy report`

Check or poll for the status of a deploy operation.

USAGE
  $ sf project deploy report [--json] [--flags-dir <value>] [-o <value>] [-i <value>] [-r] [--coverage-formatters
    clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...] [--junit]
    [--results-dir <value>] [-w <minutes>]

FLAGS
  -i, --job-id=<value>      Job ID of the deploy operation you want to check the status of.
  -o, --target-org=<value>  Username or alias of the target org.
  -r, --use-most-recent     Use the job ID of the most recent deploy operation.
  -w, --wait=<minutes>      Number of minutes to wait for command to complete and display results.

TEST FLAGS
  --coverage-formatters=<option>...  Format of the code coverage results.
                                     <options: clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|t
                                     ext|text-summary>
  --junit                            Output JUnit test results.
  --results-dir=<value>              Output directory for code coverage and JUnit results; defaults to the deploy ID.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Check or poll for the status of a deploy operation.

  Deploy operations include standard deploys, quick deploys, deploy validations, and deploy cancellations.

  Run this command by either passing it a job ID or specifying the --use-most-recent flag to use the job ID of the most
  recent deploy operation. If you specify the --wait flag, the command polls for the status every second until the
  timeout of --wait minutes. If you don't specify the --wait flag, the command simply checks and displays the status of
  the deploy; the command doesn't poll for the status.

  You typically don't specify the --target-org flag because the cached job already references the org to which you
  deployed. But if you run this command on a computer different than the one from which you deployed, then you must
  specify the --target-org and it must point to the same org.

  This command doesn't update source tracking information.

ALIASES
  $ sf deploy metadata report

EXAMPLES
  Check the status using a job ID:

    $ sf project deploy report --job-id 0Af0x000017yLUFCA2

  Check the status of the most recent deploy operation:

    $ sf project deploy report --use-most-recent

  Poll for the status using a job ID and target org:

    $ sf project deploy report --job-id 0Af0x000017yLUFCA2 --target-org [email protected] --wait 30

FLAG DESCRIPTIONS
  -i, --job-id=<value>  Job ID of the deploy operation you want to check the status of.

    These commands return a job ID if they time out or you specified the --async flag:

    - sf project deploy start
    - sf project deploy validate
    - sf project deploy quick
    - sf project deploy cancel

    The job ID is valid for 10 days from when you started the deploy operation.

  -r, --use-most-recent  Use the job ID of the most recent deploy operation.

    For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less.
    If your most recent operation was more than 3 days ago, this flag won't find a job ID.

  -w, --wait=<minutes>  Number of minutes to wait for 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 the deployment, run "sf project deploy resume". To check the status of the deployment,
    run "sf project deploy report".

  --coverage-formatters=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

See code: src/commands/project/deploy/report.ts

`sf project deploy resume`

Resume watching a deploy operation and update source tracking when the deploy completes.

USAGE
  $ sf project deploy resume [--json] [--flags-dir <value>] [--concise | --verbose] [-i <value>] [-r] [-w <minutes>]
    [--coverage-formatters clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...]
    [--junit] [--results-dir <value>]

FLAGS
  -i, --job-id=<value>   Job ID of the deploy operation you want to resume.
  -r, --use-most-recent  Use the job ID of the most recent deploy operation.
  -w, --wait=<minutes>   Number of minutes to wait for the command to complete and display results.
      --concise          Show concise output of the deploy operation result.
      --verbose          Show verbose output of the deploy operation result.

TEST FLAGS
  --coverage-formatters=<option>...  Format of the code coverage results.
                                     <options: clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|t
                                     ext|text-summary>
  --junit                            Output JUnit test results.
  --results-dir=<value>              Output directory for code coverage and JUnit results; defaults to the deploy ID.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

DESCRIPTION
  Resume watching a deploy operation and update source tracking when the deploy completes.

  Use this command to resume watching a deploy operation if the original command times out or you specified the --async
  flag. Deploy operations include standard deploys, quick deploys, deploy validations, and deploy cancellations. This
  command doesn't resume the original operation itself, because the operation always continues after you've started it,
  regardless of whether you're watching it or not. When the deploy completes, source tracking information is updated as
  needed.

  Run this command by either passing it a job ID or specifying the --use-most-recent flag to use the job ID of the most
  recent deploy operation.

ALIASES
  $ sf deploy metadata resume

EXAMPLES
  Resume watching a deploy operation using a job ID:

    $ sf project deploy resume --job-id 0Af0x000017yLUFCA2

  Resume watching the most recent deploy operation:

    $ sf project deploy resume --use-most-recent

FLAG DESCRIPTIONS
  -i, --job-id=<value>  Job ID of the deploy operation you want to resume.

    These commands return a job ID if they time out or you specified the --async flag:

    - sf project deploy start
    - sf project deploy validate
    - sf project deploy quick
    - sf project deploy cancel

    The job ID is valid for 10 days from when you started the deploy operation.

  -r, --use-most-recent  Use the job ID of the most recent deploy operation.

    For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less.
    If your most recent operation was more than 3 days ago, this flag won't find a job ID.

  -w, --wait=<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. To
    resume watching the deploy operation, run this command again. To check the status of the deploy operation, run "sf
    project deploy report".

  --coverage-formatters=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

See code: src/commands/project/deploy/resume.ts

`sf project deploy start`

Deploy metadata to an org from your local project.

USAGE
  $ sf project deploy start -o <value> [--json] [--flags-dir <value>] [-a <value>] [--async | -w <minutes>] [--concise |
    --verbose] [--dry-run] [-c] [-r] [-g] [--single-package ] [-t <value>...] [-l
    NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg] [--purge-on-delete] [--pre-destructive-changes <value>
    [-x <value> | -d <value>... | -m <value>... | --metadata-dir <value>]] [--post-destructive-changes <value> ]
    [--coverage-formatters clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...]
    [--junit] [--results-dir <value>]

FLAGS
  -a, --api-version=<value>  Target API version for the deploy.
  -c, --ignore-conflicts     Ignore conflicts and deploy local files, even if they overwrite changes in the org.
  -g, --ignore-warnings      Ignore warnings and allow a deployment to complete successfully.
  -o, --target-org=<value>   (required) Username or alias of the target org. Not required if the `target-org`
                             configuration variable is already set.
  -r, --ignore-errors        Ignore any errors and don’t roll back deployment.
  -w, --wait=<minutes>       Number of minutes to wait for command to complete and display results.
      --async                Run the command asynchronously.
      --concise              Show concise output of the deploy result.
      --dry-run              Validate deploy and run Apex tests but don’t save to the org.
      --verbose              Show verbose output of the deploy result.

SOURCE FORMAT FLAGS
  -d, --source-dir=<value>...  Path to the local source files to deploy.
  -m, --metadata=<value>...    Metadata component names to deploy. Wildcards (`*` ) supported as long as you use quotes,
                               such as `ApexClass:MyClass*`.
  -x, --manifest=<value>       Full file path for manifest (package.xml) of components to deploy.

TEST FLAGS
  -l, --test-level=<option>              Deployment Apex testing level.
                                         <options: NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg>
  -t, --tests=<value>...                 Apex tests to run when --test-level is RunSpecifiedTests.
      --coverage-formatters=<option>...  Format of the code coverage results.
                                         <options: clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamci
                                         ty|text|text-summary>
      --junit                            Output JUnit test results.
      --results-dir=<value>              Output directory for code coverage and JUnit results; defaults to the deploy
                                         ID.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

METADATA API FORMAT FLAGS
  --metadata-dir=<value>  Root of directory or zip file of metadata formatted files to deploy.
  --single-package        Indicates that the metadata zip file points to a directory structure for a single package.

DELETE FLAGS
  --post-destructive-changes=<value>  File path for a manifest (destructiveChangesPost.xml) of components to delete
                                      after the deploy.
  --pre-destructive-changes=<value>   File path for a manifest (destructiveChangesPre.xml) of components to delete
                                      before the deploy.
  --purge-on-delete                   Specify that deleted components in the destructive changes manifest file are
                                      immediately eligible for deletion rather than being stored in the Recycle Bin.

DESCRIPTION
  Deploy metadata to an org from your local project.

  You must run this command from within a project.

  Metadata components are deployed in source format by default. Deploy them in metadata format by specifying the
  --metadata-dir flag, which specifies the root directory or ZIP file that contains the metadata formatted files you
  want to deploy.

  If your org allows source tracking, then this command tracks the changes in your source. Some orgs, such as production
  orgs, never allow source tracking. Source tracking is enabled by default on scratch and sandbox orgs; you can disable
  source tracking when you create the orgs by specifying the --no-track-source flag on the "sf org create
  scratch|sandbox" commands.

  To deploy 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.

ALIASES
  $ sf deploy metadata

EXAMPLES
  Deploy local changes not in the org; uses your default org:

    $ sf project deploy start

  Deploy all source files in the "force-app" directory to an org with alias "my-scratch"; show only concise output, in
  other words don't print a list of all the source that was deployed:

    $ sf project deploy start  --source-dir force-app --target-org my-scratch --concise

  Deploy all the Apex classes and custom objects that are in the "force-app" directory. The list views, layouts, etc,
  that are associated with the custom objects are also deployed. Both examples are equivalent:

    $ sf project deploy start --source-dir force-app/main/default/classes force-app/main/default/objects
    $ sf project deploy start --source-dir force-app/main/default/classes --source-dir \
      force-app/main/default/objects

  Deploy all Apex classes that are in all package directories defined in the "sfdx-project.json" file:

    $ sf project deploy start --metadata ApexClass

  Deploy a specific Apex class; ignore any conflicts between the local project and org (be careful with this flag,
  because it will overwrite the Apex class in the org if there are conflicts!):

    $ sf project deploy start --metadata ApexClass:MyApexClass --ignore-conflicts

  Deploy specific Apex classes that match a pattern; in this example, deploy Apex classes whose names contain the
  string "MyApex". Also ignore any deployment warnings (again, be careful with this flag! You typically want to see
  the warnings):

    $ sf project deploy start --metadata 'ApexClass:MyApex*' --ignore-warnings

  Deploy a custom object called ExcitingObject that's in the SBQQ namespace:

    $ sf project deploy start --metadata CustomObject:SBQQ__ExcitingObject

  Deploy all custom objects in the SBQQ namespace by using a wildcard and quotes:

    $ sf project deploy start --metadata 'CustomObject:SBQQ__*'

  Deploy all custom objects and Apex classes found in all defined package directories (both examples are equivalent):

    $ sf project deploy start --metadata CustomObject ApexClass
    $ sf project deploy start --metadata CustomObject --metadata ApexClass

  Deploy all Apex classes and a profile that has a space in its name:

    $ sf project deploy start --metadata ApexClass --metadata "Profile:My Profile"

  Deploy all components listed in a manifest:

    $ sf project deploy start --manifest path/to/package.xml

  Run the tests that aren’t in any managed packages as part of a deployment:

    $ sf project deploy start --metadata ApexClass --test-level RunLocalTests

  Deploy all metadata formatted files in the "MDAPI" directory:

    $ sf project deploy start --metadata-dir MDAPI

  Deploy all metadata formatted files in the "MDAPI" directory; items listed in the MDAPI/destructiveChangesPre.xml
  and MDAPI/destructiveChangesPost.xml manifests are immediately eligible for deletion rather than stored in the
  Recycle Bin:

    $ sf project deploy start --metadata-dir MDAPI --purge-on-delete

FLAG DESCRIPTIONS
  -a, --api-version=<value>  Target API version for the deploy.

    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.

  -c, --ignore-conflicts  Ignore conflicts and deploy local files, even if they overwrite changes in the org.

    This flag applies only to orgs that allow source tracking. It has no effect on orgs that don't allow it, such as
    production orgs.

  -d, --source-dir=<value>...  Path to the local source files to deploy.

    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.

  -g, --ignore-warnings  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.

  -l, --test-level=NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg  Deployment Apex testing level.

    Valid values are:

    - NoTestRun — No tests are run. This test level applies only to deployments to development environments, such as
    sandbox, Developer Edition, or trial orgs. This test level is the default for development environments.

    - 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 for production deployments that include Apex classes or triggers.

    - RunAllTestsInOrg — All tests in your org are run, including tests of managed packages.

    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".

  -r, --ignore-errors  Ignore any errors and don’t roll back deployment.

    Never use this flag when deploying to a production org. If you specify it, components without errors are deployed
    and components with errors are skipped, and could result in an inconsistent production org.

  -t, --tests=<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"

  -w, --wait=<minutes>  Number of minutes to wait for 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 the deployment, run "sf project deploy resume". To check the status of the deployment,
    run "sf project deploy report".

  -x, --manifest=<value>  Full file path for manifest (package.xml) of components to deploy.

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

  --async  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 the deployment, run "sf project deploy resume". To check the status of the deployment, run "sf
    project deploy report".

  --coverage-formatters=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

See code: src/commands/project/deploy/start.ts

`sf project deploy validate`

Validate a metadata deployment without actually executing it.

USAGE
  $ sf project deploy validate -o <value> [--json] [--flags-dir <value>] [-a <value>] [--async] [--concise | --verbose] [-m
    <value>...] [-d <value>...] [--single-package --metadata-dir <value>] [-t <value>...] [-l
    RunAllTestsInOrg|RunLocalTests|RunSpecifiedTests] [-w <minutes>] [-g] [--coverage-formatters
    clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...] [--junit]
    [--results-dir <value>] [--purge-on-delete -x <value>] [--pre-destructive-changes <value> ]
    [--post-destructive-changes <value> ]

FLAGS
  -a, --api-version=<value>  Target API version for the validation.
  -g, --ignore-warnings      Ignore warnings and allow a deployment to complete successfully.
  -o, --target-org=<value>   (required) Username or alias of the target org. Not required if the `target-org`
                             configuration variable is already set.
  -w, --wait=<minutes>       Number of minutes to wait for the command to complete and display results.
      --async                Run the command asynchronously.
      --concise              Show concise output of the validation result.
      --verbose              Show verbose output of the validation result.

SOURCE FORMAT FLAGS
  -d, --source-dir=<value>...  Path to the local source files to validate for deployment.
  -m, --metadata=<value>...    Metadata component names to validate for deployment.
  -x, --manifest=<value>       Full file path for manifest (package.xml) of components to validate for deployment.

TEST FLAGS
  -l, --test-level=<option>              [default: RunLocalTests] Deployment Apex testing level.
                                         <options: RunAllTestsInOrg|RunLocalTests|RunSpecifiedTests>
  -t, --tests=<value>...                 Apex tests to run when --test-level is RunSpecifiedTests.
      --coverage-formatters=<option>...  Format of the code coverage results.
                                         <options: clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamci
                                         ty|text|text-summary>
      --junit                            Output JUnit test results.
      --results-dir=<value>              Output directory for code coverage and JUnit results; defaults to the deploy
                                         ID.

GLOBAL FLAGS
  --flags-dir=<value>  Import flag values from a directory.
  --json               Format output as json.

METADATA API FORMAT FLAGS
  --metadata-dir=<value>  Root of directory or zip file of metadata formatted files to deploy.
  --single-package        Indicates that the metadata zip file points to a directory structure for a single package.

DELETE FLAGS
  --post-destructive-changes=<value>  File path for a manifest (destructiveChangesPost.xml) of components to delete
                                      after the deploy.
  --pre-destructive-changes=<value>   File path for a manifest (destructiveChangesPre.xml) of components to delete
                                      before the deploy
  --purge-on-delete                   Specify that deleted components in the destructive changes manifest file are
                                      immediately eligible for deletion rather than being stored in the Recycle Bin.

DESCRIPTION
  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.

ALIASES
  $ sf deploy metadata validate

EXAMPLES
  NOTE: These examples focus on validating large deployments. See the help for "sf project deploy start" for examples of deploying smaller sets of metadata which you can also use to validate.

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

    $ sf project deploy validate --source-dir force-app

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

    $ sf project deploy validate --source-dir force-app --source-dir 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:

    $ sf project deploy validate --source-dir force-app --async --test-level RunAllTestsInOrg --target-org \
      my-prod-org

  Validate the deployment of all components listed in a manifest:

    $ sf project deploy validate --manifest path/to/package.xml

FLAG DESCRIPTIONS
  -a, --api-version=<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.

  -d, --source-dir=<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.

  -g, --ignore-warnings  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.

  -l, --test-level=RunAllTestsInOrg|RunLocalTests|RunSpecifiedTests  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.

  -t, --tests=<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"

  -w, --wait=<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".

  -x, --manifest=<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.

  --async  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".

  --coverage-formatters=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

See code: src/commands/project/deploy/validate.ts

`sf project generate manifest`

Create a project manifest that lists the metadata components you want to deploy or retrieve.

USAGE
  $ sf project generate manifest [--json] [--flags-dir <value>] [--api-version <value>] [-m <value>...] [-p <value>...] [-n
    <value> | -t pre|post|destroy|package] [-c managed|unlocked... --from-org <value>] [-d <value>]

FLAGS
  -c, --include-packages=<option>...  Package types (managed, unlocked) whose metadata is included in the manifest; by
                                      default, metadata in managed and unlocked packages is excluded. Metadata in
                                      unmanaged packages is always included.
                                      <options: managed|unlocked>
  -d, --output-dir=<value>            Directory to save the created manifest.
  -m, --metadata=<value>...           Names of metadata components to include in the manifest.
  -n, --name=<value>                  Name of a custom manifest file to create.
  -p, --source-dir=<value>...         Paths to the local source files to include in the manifest.
  -t, --type=<option>                 Type of manifest to create; the type determines the name of the created file.
                                      <options: pre|post|destroy|package>
      --api-version=

Published

Vulnerabilities

Links

Maintainers

Keywords

Readme

plugin-deploy-retrieve

Install

Contributing

CLA

Build

Commands

sf project convert mdapi

sf project convert source

sf project convert source-behavior

sf project delete source

sf project delete tracking

sf project deploy cancel

sf project deploy preview

sf project deploy quick

sf project deploy report

sf project deploy resume

sf project deploy start

sf project deploy validate

sf project generate manifest