{"id":35885554,"url":"https://github.com/salesforcecli/plugin-deploy-retrieve","last_synced_at":"2026-05-30T08:03:29.936Z","repository":{"id":36963573,"uuid":"357948342","full_name":"salesforcecli/plugin-deploy-retrieve","owner":"salesforcecli","description":null,"archived":false,"fork":false,"pushed_at":"2026-05-23T06:35:20.000Z","size":11378,"stargazers_count":17,"open_issues_count":11,"forks_count":34,"subscribers_count":4,"default_branch":"main","last_synced_at":"2026-05-23T06:38:06.613Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"TypeScript","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/salesforcecli.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2021-04-14T15:11:21.000Z","updated_at":"2026-05-23T06:34:33.000Z","dependencies_parsed_at":"2026-03-13T22:05:36.505Z","dependency_job_id":"28fd5efa-faa2-4adc-94a8-b0e748caa90f","html_url":"https://github.com/salesforcecli/plugin-deploy-retrieve","commit_stats":{"total_commits":562,"total_committers":24,"mean_commits":"23.416666666666668","dds":0.6548042704626335,"last_synced_commit":"f9d8ad7d0a24eb689bf9837f6bd05bb8187eeba4"},"previous_names":["salesforcecli/plugin-project"],"tags_count":554,"template":false,"template_full_name":"salesforcecli/plugin-template","purl":"pkg:github/salesforcecli/plugin-deploy-retrieve","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/salesforcecli%2Fplugin-deploy-retrieve","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/salesforcecli%2Fplugin-deploy-retrieve/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/salesforcecli%2Fplugin-deploy-retrieve/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/salesforcecli%2Fplugin-deploy-retrieve/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/salesforcecli","download_url":"https://codeload.github.com/salesforcecli/plugin-deploy-retrieve/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/salesforcecli%2Fplugin-deploy-retrieve/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33684419,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-05-30T02:00:06.278Z","response_time":92,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-08T20:09:39.840Z","updated_at":"2026-05-30T08:03:29.927Z","avatar_url":"https://github.com/salesforcecli.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# plugin-deploy-retrieve\n\n[![License](https://img.shields.io/badge/License-Apache--2.0-blue.svg)](https://opensource.org/license/apache-2-0)\n\n[![NPM](https://img.shields.io/npm/v/@salesforce/plugin-deploy-retrieve.svg?label=@salesforce/plugin-deploy-retrieve)](https://www.npmjs.com/package/@salesforce/plugin-deploy-retrieve) [![Downloads/week](https://img.shields.io/npm/dw/@salesforce/plugin-deploy-retrieve.svg)](https://npmjs.org/package/@salesforce/plugin-deploy-retrieve) [![License](https://img.shields.io/badge/License-Apache--2.0-blue.svg)](https://opensource.org/license/apache-2-0)\n\n## Install\n\n```bash\nsf plugins:install plugin-deploy-retrieve@x.y.z\n```\n\n## Contributing\n\n1. Please read our [Code of Conduct](CODE_OF_CONDUCT.md)\n2. Create a new issue before starting your project so that we can keep track of\n what you are trying to add/fix. That way, we can also offer suggestions or\n let you know if there is already an effort in progress.\n3. Fork this repository.\n4. [Build the plugin locally](#build)\n5. Create a _topic_ branch in your fork. Note, this step is recommended but technically not required if contributing using a fork.\n6. Edit the code in your fork.\n7. 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.\n8. Sign CLA (see [CLA](#cla) below).\n9. Send us a pull request when you are done. We'll review your code, suggest any needed changes, and merge it in.\n\n### CLA\n\nExternal contributors will be required to sign a Contributor's License\nAgreement. You can do so by going to https://cla.salesforce.com/sign-cla.\n\n### Build\n\nTo build the plugin locally, make sure to have yarn installed and run the following commands:\n\n```bash\n# Clone the repository\ngit clone git@github.com:salesforcecli/plugin-deploy-retrieve\n\n# Install the dependencies and compile\nyarn install\nyarn build\n```\n\nTo use your plugin, run using the local `./bin/dev.js` or `./bin/dev.cmd` file.\n\n```bash\n# Run using local run file.\n./bin/dev.js deploy\n```\n\nThere 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.\n\n```bash\n# Link your plugin to the sf cli\nsf plugins:link .\n# To verify\nsf plugins\n```\n\n## Commands\n\n\u003c!-- commands --\u003e\n\n- [`sf project convert mdapi`](#sf-project-convert-mdapi)\n- [`sf project convert source`](#sf-project-convert-source)\n- [`sf project convert source-behavior`](#sf-project-convert-source-behavior)\n- [`sf project delete source`](#sf-project-delete-source)\n- [`sf project delete tracking`](#sf-project-delete-tracking)\n- [`sf project deploy cancel`](#sf-project-deploy-cancel)\n- [`sf project deploy preview`](#sf-project-deploy-preview)\n- [`sf project deploy quick`](#sf-project-deploy-quick)\n- [`sf project deploy report`](#sf-project-deploy-report)\n- [`sf project deploy resume`](#sf-project-deploy-resume)\n- [`sf project deploy start`](#sf-project-deploy-start)\n- [`sf project deploy validate`](#sf-project-deploy-validate)\n- [`sf project generate manifest`](#sf-project-generate-manifest)\n- [`sf project list ignored`](#sf-project-list-ignored)\n- [`sf project reset tracking`](#sf-project-reset-tracking)\n- [`sf project retrieve preview`](#sf-project-retrieve-preview)\n- [`sf project retrieve start`](#sf-project-retrieve-start)\n\n## `sf project convert mdapi`\n\nConvert metadata retrieved via Metadata API into the source format used in Salesforce DX projects.\n\n```\nUSAGE\n $ sf project convert mdapi -r \u003cvalue\u003e [--json] [--flags-dir \u003cvalue\u003e] [--api-version \u003cvalue\u003e] [-d \u003cvalue\u003e] [-p \u003cvalue\u003e...\n | -x \u003cvalue\u003e | -m \u003cvalue\u003e...]\n\nFLAGS\n -d, --output-dir=\u003cvalue\u003e Directory to store your files in after they’re converted to source format; can be an\n absolute or relative path.\n -m, --metadata=\u003cvalue\u003e... Metadata component names to convert.\n -p, --metadata-dir=\u003cvalue\u003e... Root of directory or zip file of metadata formatted files to convert.\n -r, --root-dir=\u003cvalue\u003e (required) Root directory that contains the Metadata API–formatted metadata.\n -x, --manifest=\u003cvalue\u003e File path to manifest (package.xml) of metadata types to convert.\n --api-version=\u003cvalue\u003e Override the api version used for api requests made by this command\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Convert metadata retrieved via Metadata API into the source format used in Salesforce DX projects.\n\n To use Salesforce CLI to work with components that you retrieved via Metadata API, first convert your files from the\n metadata format to the source format using this command.\n\n To convert files from the source format back to the metadata format, run \"sf project convert source\".\n\n To convert multiple metadata components, either set multiple --metadata \u003cname\u003e flags or a single --metadata flag with\n multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax\n applies to --source-dir.\n\nALIASES\n $ sf force mdapi convert\n\nEXAMPLES\n Convert metadata formatted files in the specified directory into source formatted files; writes converted files to\n your default package directory:\n\n $ sf project convert mdapi --root-dir path/to/metadata\n\n Similar to previous example, but writes converted files to the specified output directory:\n\n $ sf project convert mdapi --root-dir path/to/metadata --output-dir path/to/outputdir\n\nFLAG DESCRIPTIONS\n -p, --metadata-dir=\u003cvalue\u003e... Root of directory or zip file of metadata formatted files to convert.\n\n The supplied paths can be to a single file (in which case the operation is applied to only one file) or to a folder\n (in which case the operation is applied to all metadata types in the directory and its sub-directories).\n\n If you specify this flag, don’t specify --manifest or --metadata. If the comma-separated list you’re supplying\n contains spaces, enclose the entire comma-separated list in one set of double quotes.\n\n -x, --manifest=\u003cvalue\u003e File path to manifest (package.xml) of metadata types to convert.\n\n If you specify this flag, don’t specify --metadata or --source-dir.\n```\n\n_See code: [src/commands/project/convert/mdapi.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/convert/mdapi.ts)_\n\n## `sf project convert source`\n\nConvert source-formatted files into metadata that you can deploy using Metadata API.\n\n```\nUSAGE\n $ sf project convert source [--json] [--flags-dir \u003cvalue\u003e] [--api-version \u003cvalue\u003e] [-r \u003cvalue\u003e] [-d \u003cvalue\u003e] [-n \u003cvalue\u003e]\n [-p \u003cvalue\u003e... | -x \u003cvalue\u003e | -m \u003cvalue\u003e...]\n\nFLAGS\n -d, --output-dir=\u003cvalue\u003e [default: metadataPackage_\u003etimestamp\u003c] Output directory to store the Metadata\n API–formatted files in.\n -m, --metadata=\u003cvalue\u003e... Metadata component names to convert.\n -n, --package-name=\u003cvalue\u003e Name of the package to associate with the metadata-formatted files.\n -p, --source-dir=\u003cvalue\u003e... Paths to the local source files to convert.\n -r, --root-dir=\u003cvalue\u003e Source directory other than the default package to convert.\n -x, --manifest=\u003cvalue\u003e Path to the manifest (package.xml) file that specifies the metadata types to convert.\n --api-version=\u003cvalue\u003e API Version to use in the generated project's manifest. By default, will use the version\n from sfdx-project.json\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Convert source-formatted files into metadata that you can deploy using Metadata API.\n\n To convert source-formatted files into the metadata format, so that you can deploy them using Metadata API, run this\n command. Then deploy the metadata using \"sf project deploy\".\n\n To convert Metadata API–formatted files into the source format, run \"sf project convert mdapi\".\n\n To specify a package name that includes spaces, enclose the name in single quotes.\n\n To convert multiple components, either set multiple --metadata \u003cname\u003e flags or a single --metadata flag with multiple\n names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax applies to\n --source-dir.\n\nALIASES\n $ sf force source convert\n\nEXAMPLES\n Convert source-formatted files in the specified directory into metadata-formatted files; writes converted files into\n a new directory:\n\n $ sf project convert source --root-dir path/to/source\n\n Similar to previous example, but writes converted files to the specified output directory and associates the files\n with the specified package:\n\n $ sf project convert source --root-dir path/to/source --output-dir path/to/outputdir --package-name 'My Package'\n\nFLAG DESCRIPTIONS\n -p, --source-dir=\u003cvalue\u003e... Paths to the local source files to convert.\n\n The supplied paths can be to a single file (in which case the operation is applied to only one file) or to a folder\n (in which case the operation is applied to all metadata types in the directory and its sub-directories).\n\n If you specify this flag, don’t specify --manifest or --metadata.\n\n -x, --manifest=\u003cvalue\u003e Path to the manifest (package.xml) file that specifies the metadata types to convert.\n\n If you specify this flag, don’t specify --metadata or --source-dir.\n\n --api-version=\u003cvalue\u003e\n\n API Version to use in the generated project's manifest. By default, will use the version from sfdx-project.json\n\n Override the api version used for api requests made by this command\n```\n\n_See code: [src/commands/project/convert/source.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/convert/source.ts)_\n\n## `sf project convert source-behavior`\n\nEnable a behavior of your project source files, and then update your Salesforce DX project to implement the behavior.\n\n```\nUSAGE\n $ sf project convert source-behavior -b\n decomposeCustomLabelsBeta2|decomposeCustomLabelsBeta|decomposePermissionSetBeta|decomposePermissionSetBeta2|decompos\n eSharingRulesBeta|decomposeWorkflowBeta|decomposeExternalServiceRegistrationBeta [--json] [--flags-dir \u003cvalue\u003e]\n [--dry-run] [--preserve-temp-dir] [-o \u003cvalue\u003e]\n\nFLAGS\n -b, --behavior=\u003coption\u003e (required) Behavior to enable; the values correspond to the possible values of the\n \"sourceBehaviorOption\" option in the \"sfdx-project.json\" file.\n \u003coptions: decomposeCustomLabelsBeta2|decomposeCustomLabelsBeta|decomposePermissionSetBeta|de\n composePermissionSetBeta2|decomposeSharingRulesBeta|decomposeWorkflowBeta|decomposeExternalS\n erviceRegistrationBeta\u003e\n -o, --target-org=\u003cvalue\u003e Username or alias of the target org.\n --dry-run Display what the command would do, but don't make any actual changes.\n --preserve-temp-dir Don't delete the metadata API format temporary directory that this command creates. Useful\n for debugging.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Enable a behavior of your project source files, and then update your Salesforce DX project to implement the behavior.\n\n Specifically, this command updates the \"sourceBehaviorOption\" option in the \"sfdx-project.json\" file and then converts\n the associated local source files in your project as needed.\n\n For example, run this command with the \"--behavior decomposePermissionSetBeta\" flag to start decomposing permission\n sets when you deploy or retrieve them. Decomposing means breaking up the monolithic metadata API format XML file that\n corresponds to a metadata component into smaller XML files and directories based on its subtypes. Permission sets are\n not decomposed by default; you must opt-in to start decomposing them by using this command. When the command finishes,\n your \"sfdx-project.json\" file is updated to always decompose permission sets, and the existing permission set files in\n your local package directories are converted into the new decomposed format. You run this command only once for a\n given behavior change.\n\n For more information about the possible values for the --behavior flag, see the \"sourceBehaviorOptions\" section in the\n https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_config.htm topic.\n\nEXAMPLES\n Update your Salesforce DX project to decompose custom permission sets:\n\n $ sf project convert source-behavior --behavior decomposePermissionSetBeta\n\n Display what the command would do, but don't change any existing files:\n\n $ sf project convert source-behavior --behavior decomposePermissionSetBeta --dry-run\n\n Keep the temporary directory that contains the interim metadata API formatted files:\n\n $ sf project convert source-behavior --behavior decomposePermissionSetBeta --dry-run --preserve-temp-dir\n```\n\n_See code: [src/commands/project/convert/source-behavior.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/convert/source-behavior.ts)_\n\n## `sf project delete source`\n\nDelete source from your project and from a non-source-tracked org.\n\n```\nUSAGE\n $ sf project delete source -o \u003cvalue\u003e [--json] [--flags-dir \u003cvalue\u003e] [--api-version \u003cvalue\u003e] [-w \u003cvalue\u003e] [--tests\n \u003cvalue\u003e...] [-l NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg|RunRelevantTests] [-r] [-m \u003cvalue\u003e...]\n [-p \u003cvalue\u003e...] [-f [-t | -c]] [--verbose]\n\nFLAGS\n -c, --check-only Validate delete command but don't delete anything from the org or the local project.\n -f, --force-overwrite Ignore conflict warnings and overwrite changes to the org.\n -m, --metadata=\u003cvalue\u003e... Metadata components to delete.\n -o, --target-org=\u003cvalue\u003e (required) Username or alias of the target org. Not required if the `target-org`\n configuration variable is already set.\n -p, --source-dir=\u003cvalue\u003e... Source file paths to delete.\n -r, --no-prompt Don't prompt for delete confirmation.\n -t, --track-source If the delete succeeds, update the source tracking information.\n -w, --wait=\u003cvalue\u003e Number of minutes to wait for the command to finish.\n --api-version=\u003cvalue\u003e Override the api version used for api requests made by this command\n --verbose Verbose output of the delete result.\n\nTEST FLAGS\n -l, --test-level=\u003coption\u003e Deployment Apex testing level.\n \u003coptions: NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg|RunRelevantTests\u003e\n --tests=\u003cvalue\u003e... Apex tests to run when --test-level is RunSpecifiedTests.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Delete source from your project and from a non-source-tracked org.\n\n Use this command to delete components from orgs that don’t have source tracking. To remove deleted items from orgs\n that have source tracking enabled, \"sf project deploy start\".\n\n When you run this command, both the local source file and the metadata component in the org are deleted.\n\n To delete multiple metadata components, either set multiple --metadata \u003cname\u003e flags or a single --metadata flag with\n multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax\n applies to --source-dir.\n\nALIASES\n $ sf force source delete\n\nEXAMPLES\n Delete all local Apex source files and all Apex classes from the org with alias \"my-scratch\":\n\n $ sf project delete source --metadata ApexClass --target-org my-scratch\n\n Delete a specific Apex class and a Profile that has a space in it from your default org; don't prompt for\n confirmation:\n\n $ sf project delete source --metadata ApexClass:MyFabulousApexClass --metadata \"Profile: My Profile\" --no-prompt\n\n Run the tests that aren’t in any managed packages as part of the deletion; if the delete succeeds, and the org has\n source-tracking enabled, update the source tracking information:\n\n $ sf project delete source --metadata ApexClass --test-level RunLocalTests --track-source\n\n Delete the Apex source files in a directory and the corresponding components from your default org:\n\n $ sf project delete source --source-dir force-app/main/default/classes\n\nFLAG DESCRIPTIONS\n -c, --check-only Validate delete command but don't delete anything from the org or the local project.\n\n IMPORTANT: Where possible, we changed noninclusive terms to align with our company value of Equality. We maintained\n certain terms to avoid any effect on customer implementations.\n\n Validates the deleted metadata and runs all Apex tests, but prevents the deletion from being saved to the org.\n\n If you change a field type from Master-Detail to Lookup or vice versa, that change isn’t supported when using the\n --check-only flag to test a deletion (validation). This kind of change isn’t supported for test deletions to avoid\n the risk of data loss or corruption. If a change that isn’t supported for test deletions is included in a deletion\n package, the test deletion fails and issues an error.\n\n If your deletion package changes a field type from Master-Detail to Lookup or vice versa, you can still validate the\n changes prior to deploying to Production by performing a full deletion to another test Sandbox. A full deletion\n includes a validation of the changes as part of the deletion process.\n\n Note: A Metadata API deletion that includes Master-Detail relationships deletes all detail records in the Recycle\n Bin in the following cases.\n\n 1. For a deletion with a new Master-Detail field, soft delete (send to the Recycle Bin) all detail records before\n proceeding to delete the Master-Detail field, or the deletion fails. During the deletion, detail records are\n permanently deleted from the Recycle Bin and cannot be recovered.\n\n 2. For a deletion that converts a Lookup field relationship to a Master-Detail relationship, detail records must\n reference a master record or be soft-deleted (sent to the Recycle Bin) for the deletion to succeed. However, a\n successful deletion permanently deletes any detail records in the Recycle Bin.\n\n -l, --test-level=NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg|RunRelevantTests\n\n Deployment Apex testing level.\n\n Valid values are:\n\n - NoTestRun — No tests are run. This test level applies only to deployments to development environments, such as\n sandbox, Developer Edition, or trial orgs. This test level is the default for development environments.\n\n - RunSpecifiedTests — Runs only the tests that you specify with the --tests flag. Code coverage requirements differ\n from the default coverage requirements when using this test level. Executed tests must comprise a minimum of 75%\n code coverage for each class and trigger in the deployment package. This coverage is computed for each class and\n trigger individually and is different than the overall coverage percentage.\n\n - RunLocalTests — All tests in your org are run, except the ones that originate from installed managed and unlocked\n packages. This test level is the default for production deployments that include Apex classes or triggers.\n\n - RunAllTestsInOrg — All tests in your org are run, including tests of managed packages.\n\n - RunRelevantTests (Beta) — Runs only tests that are relevant to the files being deployed. Salesforce automatically\n identifies the relevant tests based on an analysis of the deployment payload and the payload dependencies. For\n fine-grained control, you can also annotate test classes so that they always run in certain conditions. See \"@IsTest\n Annotation\" in the \"Apex Developer Guide\"\n (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_annotation_isTest.htm). Each\n class and trigger in the deployment package must be covered by the executed tests for a minimum of 75% code\n coverage. This coverage is computed for each class and triggers individually and is different than the overall\n coverage percentage.\n\n If you don’t specify a test level, the default behavior depends on the contents of your deployment package and\n target org. For more information, see \"Running Tests in a Deployment\"\n (https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_running_tests.htm) in the\n \"Metadata API Developer Guide\".\n\n -m, --metadata=\u003cvalue\u003e... Metadata components to delete.\n\n If you specify this flag, don’t specify --source-dir.\n\n -p, --source-dir=\u003cvalue\u003e... Source file paths to delete.\n\n The supplied paths can be a single file (in which case the operation is applied to only one file) or a folder (in\n which case the operation is applied to all metadata types in the directory and its sub-directories).\n\n If you specify this flag, don’t specify --metadata.\n\n -w, --wait=\u003cvalue\u003e Number of minutes to wait for the command to finish.\n\n If the command continues to run after the wait period, the CLI returns control of the terminal window to you.\n\n --tests=\u003cvalue\u003e... Apex tests to run when --test-level is RunSpecifiedTests.\n\n If a test name contains a space, enclose it in double quotes.\n For multiple test names, use one of the following formats:\n\n - Repeat the flag for multiple test names: --tests Test1 --tests Test2 --tests \"Test With Space\"\n - Separate the test names with spaces: --tests Test1 Test2 \"Test With Space\"\n```\n\n_See code: [src/commands/project/delete/source.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/delete/source.ts)_\n\n## `sf project delete tracking`\n\nDelete all local source tracking information.\n\n```\nUSAGE\n $ sf project delete tracking -o \u003cvalue\u003e [--json] [--flags-dir \u003cvalue\u003e] [--api-version \u003cvalue\u003e] [-p]\n\nFLAGS\n -o, --target-org=\u003cvalue\u003e (required) Username or alias of the target org. Not required if the `target-org`\n configuration variable is already set.\n -p, --no-prompt Don't prompt for source tracking override confirmation.\n --api-version=\u003cvalue\u003e Override the api version used for api requests made by this command\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Delete all local source tracking information.\n\n WARNING: This command deletes or overwrites all existing source tracking files. Use with extreme caution.\n\n Deletes all local source tracking information. When you next run 'project deploy preview', Salesforce CLI displays all\n local and remote files as changed, and any files with the same name are listed as conflicts.\n\nALIASES\n $ sf force source tracking clear\n\nEXAMPLES\n Delete local source tracking for the org with alias \"my-scratch\":\n\n $ sf project delete tracking --target-org my-scratch\n```\n\n_See code: [src/commands/project/delete/tracking.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/delete/tracking.ts)_\n\n## `sf project deploy cancel`\n\nCancel a deploy operation.\n\n```\nUSAGE\n $ sf project deploy cancel [--json] [--flags-dir \u003cvalue\u003e] [-o \u003cvalue\u003e] [--async | -w \u003cminutes\u003e] [-i \u003cvalue\u003e] [-r]\n\nFLAGS\n -i, --job-id=\u003cvalue\u003e Job ID of the deploy operation you want to cancel.\n -o, --target-org=\u003cvalue\u003e Username or alias of the target org.\n -r, --use-most-recent Use the job ID of the most recent deploy operation.\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for the command to complete and display results.\n --async Run the command asynchronously.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Cancel a deploy operation.\n\n Use this command to cancel a deploy operation that hasn't yet completed in the org. Deploy operations include standard\n deploys, quick deploys, deploy validations, and deploy cancellations.\n\n 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\n recent deploy operation.\n\nALIASES\n $ sf deploy metadata cancel\n\nEXAMPLES\n Cancel a deploy operation using a job ID:\n\n $ sf project deploy cancel --job-id 0Af0x000017yLUFCA2\n\n Cancel the most recent deploy operation:\n\n $ sf project deploy cancel --use-most-recent\n\nFLAG DESCRIPTIONS\n -i, --job-id=\u003cvalue\u003e Job ID of the deploy operation you want to cancel.\n\n These commands return a job ID if they time out or you specified the --async flag:\n\n - sf project deploy start\n - sf project deploy validate\n - sf project deploy quick\n - sf project deploy cancel\n\n The job ID is valid for 10 days from when you started the deploy operation.\n\n -r, --use-most-recent Use the job ID of the most recent deploy operation.\n\n For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less.\n If your most recent deploy operations was more than 3 days ago, this flag won't find a job ID.\n\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for the command to complete and display results.\n\n If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To\n resume watching the cancellation, run \"sf project deploy resume\". To check the status of the cancellation, run \"sf\n project deploy report\".\n\n --async Run the command asynchronously.\n\n The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To\n resume watching the cancellation, run \"sf project deploy resume\". To check the status of the cancellation, run \"sf\n project deploy report\".\n```\n\n_See code: [src/commands/project/deploy/cancel.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/deploy/cancel.ts)_\n\n## `sf project deploy preview`\n\nPreview a deployment to see what will deploy to the org, the potential conflicts, and the ignored files.\n\n```\nUSAGE\n $ sf project deploy preview -o \u003cvalue\u003e [--json] [--flags-dir \u003cvalue\u003e] [-c] [-x \u003cvalue\u003e | -d \u003cvalue\u003e... | -m \u003cvalue\u003e...]\n [--concise]\n\nFLAGS\n -c, --ignore-conflicts Don't display conflicts in preview of the deployment.\n -d, --source-dir=\u003cvalue\u003e... Path to the local source files to preview.\n -m, --metadata=\u003cvalue\u003e... Metadata component names to preview.\n -o, --target-org=\u003cvalue\u003e (required) Username or alias of the target org. Not required if the `target-org`\n configuration variable is already set.\n -x, --manifest=\u003cvalue\u003e Full file path for manifest (package.xml) of components to preview.\n --concise Show only the changes that will be deployed; omits files that are forceignored.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Preview a deployment to see what will deploy to the org, the potential conflicts, and the ignored files.\n\n You must run this command from within a project.\n\n The command outputs a table that describes what will happen if you run the \"sf project deploy start\" command. The\n table lists the metadata components that will be deployed and deleted. The table also lists the current conflicts\n between files in your local project and components in the org. Finally, the table lists the files that won't be\n deployed because they're included in your .forceignore file.\n\n If your org allows source tracking, then this command displays potential conflicts between the org and your local\n project. Some orgs, such as production org, never allow source tracking. Source tracking is enabled by default on\n scratch and sandbox orgs; you can disable source tracking when you create the orgs by specifying the --no-track-source\n flag on the \"sf org create scratch|sandbox\" commands.\n\n To preview the deployment of multiple metadata components, either set multiple --metadata \u003cname\u003e flags or a single\n --metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double\n quotes. The same syntax applies to --source-dir.\n\nALIASES\n $ sf deploy metadata preview\n\nEXAMPLES\n 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.\n\n Preview the deployment of source files in a directory, such as force-app, to your default org:\n\n $ sf project deploy preview --source-dir force-app\n\n Preview the deployment of all Apex classes to an org with alias \"my-scratch\":\n\n $ sf project deploy preview --metadata ApexClass --target-org my-scratch\n\n Preview deployment of a specific Apex class:\n\n $ sf project deploy preview --metadata ApexClass:MyApexClass\n\n Preview deployment of all components listed in a manifest:\n\n $ sf project deploy preview --manifest path/to/package.xml\n\nFLAG DESCRIPTIONS\n -c, --ignore-conflicts Don't display conflicts in preview of the deployment.\n\n This flag applies only to orgs that allow source tracking. It has no effect on orgs that don't allow it, such as\n production orgs.\n\n -d, --source-dir=\u003cvalue\u003e... Path to the local source files to preview.\n\n The supplied path can be to a single file (in which case the operation is applied to only one file) or to a folder\n (in which case the operation is applied to all metadata types in the directory and its subdirectories).\n\n If you specify this flag, don’t specify --metadata or --manifest.\n\n -x, --manifest=\u003cvalue\u003e Full file path for manifest (package.xml) of components to preview.\n\n All child components are included. If you specify this flag, don’t specify --metadata or --source-dir.\n```\n\n_See code: [src/commands/project/deploy/preview.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/deploy/preview.ts)_\n\n## `sf project deploy quick`\n\nQuickly deploy a validated deployment to an org.\n\n```\nUSAGE\n $ sf project deploy quick [--json] [--flags-dir \u003cvalue\u003e] [--async | -w \u003cminutes\u003e] [--concise | --verbose] [-i \u003cvalue\u003e]\n [-o \u003cvalue\u003e] [-r] [-a \u003cvalue\u003e]\n\nFLAGS\n -a, --api-version=\u003cvalue\u003e Target API version for the deploy.\n -i, --job-id=\u003cvalue\u003e Job ID of the deployment you want to quick deploy.\n -o, --target-org=\u003cvalue\u003e Username or alias of the target org.\n -r, --use-most-recent Use the job ID of the most recently validated deployment.\n -w, --wait=\u003cminutes\u003e [default: 33 minutes] Number of minutes to wait for the command to complete and display\n results.\n --async Run the command asynchronously.\n --concise Show concise output of the deploy result.\n --verbose Show verbose output of the deploy result.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Quickly deploy a validated deployment to an org.\n\n Before you run this command, first create a validated deployment with the \"sf project deploy validate\" command, which\n returns a job ID. Validated deployments haven't been deployed to the org yet; you deploy them with this command.\n Either pass the job ID to this command or use the --use-most-recent flag to use the job ID of the most recently\n validated deployment. For the quick deploy to succeed, the associated validated deployment must also have succeeded.\n\n Executing this quick deploy command takes less time than a standard deploy because it skips running Apex tests. These\n tests were previously run as part of the validation. Validating first and then running a quick deploy is useful if the\n deployment to your production org take several hours and you don’t want to risk a failed deploy.\n\n This command doesn't support source-tracking. The source you deploy overwrites the corresponding metadata in your org.\n This command doesn’t attempt to merge your source with the versions in your org.\n\n Note: Don't use this command on sandboxes; the command is intended to be used on production orgs. By default,\n sandboxes don't run tests during a deploy. Use \"sf project deploy start\" instead.\n\nALIASES\n $ sf deploy metadata quick\n\nEXAMPLES\n Run a quick deploy to your default org using a job ID:\n\n $ sf project deploy quick --job-id 0Af0x000017yLUFCA2\n\n Asynchronously run a quick deploy of the most recently validated deployment to an org with alias \"my-prod-org\":\n\n $ sf project deploy quick --async --use-most-recent --target-org my-prod-org\n\nFLAG DESCRIPTIONS\n -a, --api-version=\u003cvalue\u003e Target API version for the deploy.\n\n Use this flag to override the default API version with the API version of your package.xml file. The default API\n version is the latest version supported by the CLI.\n\n -i, --job-id=\u003cvalue\u003e Job ID of the deployment you want to quick deploy.\n\n The job ID is valid for 10 days from when you started the validation.\n\n -r, --use-most-recent Use the job ID of the most recently validated deployment.\n\n For performance reasons, this flag uses only job IDs that were validated in the past 3 days or less. If your most\n recent deployment validation was more than 3 days ago, this flag won't find a job ID.\n\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for the command to complete and display results.\n\n If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To\n resume watching the deploy, run \"sf project deploy resume\". To check the status of the deploy, run \"sf project\n deploy report\".\n\n --async Run the command asynchronously.\n\n The command immediately returns the control of the terminal to you. This way, you can continue to use the CLI. To\n resume watching the deploy, run \"sf project deploy resume\". To check the status of the deploy, run \"sf project\n deploy report\".\n```\n\n_See code: [src/commands/project/deploy/quick.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/deploy/quick.ts)_\n\n## `sf project deploy report`\n\nCheck or poll for the status of a deploy operation.\n\n```\nUSAGE\n $ sf project deploy report [--json] [--flags-dir \u003cvalue\u003e] [-o \u003cvalue\u003e] [-i \u003cvalue\u003e] [-r] [--coverage-formatters\n clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...] [--junit]\n [--results-dir \u003cvalue\u003e] [-w \u003cminutes\u003e]\n\nFLAGS\n -i, --job-id=\u003cvalue\u003e Job ID of the deploy operation you want to check the status of.\n -o, --target-org=\u003cvalue\u003e Username or alias of the target org.\n -r, --use-most-recent Use the job ID of the most recent deploy operation.\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for command to complete and display results.\n\nTEST FLAGS\n --coverage-formatters=\u003coption\u003e... Format of the code coverage results.\n \u003coptions: clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|t\n ext|text-summary\u003e\n --junit Output JUnit test results.\n --results-dir=\u003cvalue\u003e Output directory for code coverage and JUnit results; defaults to the deploy ID.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Check or poll for the status of a deploy operation.\n\n Deploy operations include standard deploys, quick deploys, deploy validations, and deploy cancellations.\n\n 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\n recent deploy operation. If you specify the --wait flag, the command polls for the status every second until the\n timeout of --wait minutes. If you don't specify the --wait flag, the command simply checks and displays the status of\n the deploy; the command doesn't poll for the status.\n\n You typically don't specify the --target-org flag because the cached job already references the org to which you\n deployed. But if you run this command on a computer different than the one from which you deployed, then you must\n specify the --target-org and it must point to the same org.\n\n This command doesn't update source tracking information.\n\nALIASES\n $ sf deploy metadata report\n\nEXAMPLES\n Check the status using a job ID:\n\n $ sf project deploy report --job-id 0Af0x000017yLUFCA2\n\n Check the status of the most recent deploy operation:\n\n $ sf project deploy report --use-most-recent\n\n Poll for the status using a job ID and target org:\n\n $ sf project deploy report --job-id 0Af0x000017yLUFCA2 --target-org me@my.org --wait 30\n\nFLAG DESCRIPTIONS\n -i, --job-id=\u003cvalue\u003e Job ID of the deploy operation you want to check the status of.\n\n These commands return a job ID if they time out or you specified the --async flag:\n\n - sf project deploy start\n - sf project deploy validate\n - sf project deploy quick\n - sf project deploy cancel\n\n The job ID is valid for 10 days from when you started the deploy operation.\n\n -r, --use-most-recent Use the job ID of the most recent deploy operation.\n\n For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less.\n If your most recent operation was more than 3 days ago, this flag won't find a job ID.\n\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for command to complete and display results.\n\n If the command continues to run after the wait period, the CLI returns control of the terminal window to you and\n returns the job ID. To resume the deployment, run \"sf project deploy resume\". To check the status of the deployment,\n run \"sf project deploy report\".\n\n --coverage-formatters=clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...\n\n Format of the code coverage results.\n\n For multiple formatters, repeat the flag for each formatter.\n --coverage-formatters lcov --coverage-formatters clover\n```\n\n_See code: [src/commands/project/deploy/report.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/deploy/report.ts)_\n\n## `sf project deploy resume`\n\nResume watching a deploy operation and update source tracking when the deploy completes.\n\n```\nUSAGE\n $ sf project deploy resume [--json] [--flags-dir \u003cvalue\u003e] [--concise | --verbose] [-i \u003cvalue\u003e] [-r] [-w \u003cminutes\u003e]\n [--coverage-formatters clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...]\n [--junit] [--results-dir \u003cvalue\u003e]\n\nFLAGS\n -i, --job-id=\u003cvalue\u003e Job ID of the deploy operation you want to resume.\n -r, --use-most-recent Use the job ID of the most recent deploy operation.\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for the command to complete and display results.\n --concise Show concise output of the deploy operation result.\n --verbose Show verbose output of the deploy operation result.\n\nTEST FLAGS\n --coverage-formatters=\u003coption\u003e... Format of the code coverage results.\n \u003coptions: clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|t\n ext|text-summary\u003e\n --junit Output JUnit test results.\n --results-dir=\u003cvalue\u003e Output directory for code coverage and JUnit results; defaults to the deploy ID.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Resume watching a deploy operation and update source tracking when the deploy completes.\n\n Use this command to resume watching a deploy operation if the original command times out or you specified the --async\n flag. Deploy operations include standard deploys, quick deploys, deploy validations, and deploy cancellations. This\n command doesn't resume the original operation itself, because the operation always continues after you've started it,\n regardless of whether you're watching it or not. When the deploy completes, source tracking information is updated as\n needed.\n\n 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\n recent deploy operation.\n\nALIASES\n $ sf deploy metadata resume\n\nEXAMPLES\n Resume watching a deploy operation using a job ID:\n\n $ sf project deploy resume --job-id 0Af0x000017yLUFCA2\n\n Resume watching the most recent deploy operation:\n\n $ sf project deploy resume --use-most-recent\n\nFLAG DESCRIPTIONS\n -i, --job-id=\u003cvalue\u003e Job ID of the deploy operation you want to resume.\n\n These commands return a job ID if they time out or you specified the --async flag:\n\n - sf project deploy start\n - sf project deploy validate\n - sf project deploy quick\n - sf project deploy cancel\n\n The job ID is valid for 10 days from when you started the deploy operation.\n\n -r, --use-most-recent Use the job ID of the most recent deploy operation.\n\n For performance reasons, this flag uses job IDs for deploy operations that started only in the past 3 days or less.\n If your most recent operation was more than 3 days ago, this flag won't find a job ID.\n\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for the command to complete and display results.\n\n If the command continues to run after the wait period, the CLI returns control of the terminal window to you. To\n resume watching the deploy operation, run this command again. To check the status of the deploy operation, run \"sf\n project deploy report\".\n\n --coverage-formatters=clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...\n\n Format of the code coverage results.\n\n For multiple formatters, repeat the flag for each formatter.\n --coverage-formatters lcov --coverage-formatters clover\n```\n\n_See code: [src/commands/project/deploy/resume.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/deploy/resume.ts)_\n\n## `sf project deploy start`\n\nDeploy metadata to an org from your local project.\n\n```\nUSAGE\n $ sf project deploy start -o \u003cvalue\u003e [--json] [--flags-dir \u003cvalue\u003e] [-a \u003cvalue\u003e] [--async | -w \u003cminutes\u003e] [--concise |\n --verbose] [--dry-run] [-c] [-r] [-g] [--single-package ] [-t \u003cvalue\u003e...] [-l\n NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg|RunRelevantTests] [--purge-on-delete]\n [--pre-destructive-changes \u003cvalue\u003e [-x \u003cvalue\u003e | -d \u003cvalue\u003e... | -m \u003cvalue\u003e... | --metadata-dir \u003cvalue\u003e]]\n [--post-destructive-changes \u003cvalue\u003e ] [--coverage-formatters\n clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...] [--junit]\n [--results-dir \u003cvalue\u003e]\n\nFLAGS\n -a, --api-version=\u003cvalue\u003e Target API version for the deploy.\n -c, --ignore-conflicts Ignore conflicts and deploy local files, even if they overwrite changes in the org.\n -g, --ignore-warnings Ignore warnings and allow a deployment to complete successfully.\n -o, --target-org=\u003cvalue\u003e (required) Username or alias of the target org. Not required if the `target-org`\n configuration variable is already set.\n -r, --ignore-errors Ignore any errors and don’t roll back deployment.\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for command to complete and display results.\n --async Run the command asynchronously.\n --concise Show concise output of the deploy result.\n --dry-run Validate deploy and run Apex tests but don’t save to the org.\n --verbose Show verbose output of the deploy result.\n\nSOURCE FORMAT FLAGS\n -d, --source-dir=\u003cvalue\u003e... Path to the local source files to deploy.\n -m, --metadata=\u003cvalue\u003e... Metadata component names to deploy. Wildcards (`*` ) supported as long as you use quotes,\n such as `ApexClass:MyClass*`.\n -x, --manifest=\u003cvalue\u003e Full file path for manifest (package.xml) of components to deploy.\n\nTEST FLAGS\n -l, --test-level=\u003coption\u003e Deployment Apex testing level.\n \u003coptions:\n NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg|RunRelevantTests\u003e\n -t, --tests=\u003cvalue\u003e... Apex tests to run when --test-level is RunSpecifiedTests.\n --coverage-formatters=\u003coption\u003e... Format of the code coverage results.\n \u003coptions: clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamci\n ty|text|text-summary\u003e\n --junit Output JUnit test results.\n --results-dir=\u003cvalue\u003e Output directory for code coverage and JUnit results; defaults to the deploy\n ID.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nMETADATA API FORMAT FLAGS\n --metadata-dir=\u003cvalue\u003e Root of directory or zip file of metadata formatted files to deploy.\n --single-package Indicates that the metadata zip file points to a directory structure for a single package.\n\nDELETE FLAGS\n --post-destructive-changes=\u003cvalue\u003e File path for a manifest (destructiveChangesPost.xml) of components to delete\n after the deploy.\n --pre-destructive-changes=\u003cvalue\u003e File path for a manifest (destructiveChangesPre.xml) of components to delete\n before the deploy.\n --purge-on-delete Specify that deleted components in the destructive changes manifest file are\n immediately eligible for deletion rather than being stored in the Recycle Bin.\n\nDESCRIPTION\n Deploy metadata to an org from your local project.\n\n You must run this command from within a project.\n\n Metadata components are deployed in source format by default. Deploy them in metadata format by specifying the\n --metadata-dir flag, which specifies the root directory or ZIP file that contains the metadata formatted files you\n want to deploy.\n\n If your org allows source tracking, then this command tracks the changes in your source. Some orgs, such as production\n orgs, never allow source tracking. Source tracking is enabled by default on scratch and sandbox orgs; you can disable\n source tracking when you create the orgs by specifying the --no-track-source flag on the \"sf org create\n scratch|sandbox\" commands.\n\n To deploy multiple metadata components, either set multiple --metadata \u003cname\u003e flags or a single --metadata flag with\n multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax\n applies to --source-dir.\n\nALIASES\n $ sf deploy metadata\n\nEXAMPLES\n Deploy local changes not in the org; uses your default org:\n\n $ sf project deploy start\n\n Deploy all source files in the \"force-app\" directory to an org with alias \"my-scratch\"; show only concise output, in\n other words don't print a list of all the source that was deployed:\n\n $ sf project deploy start --source-dir force-app --target-org my-scratch --concise\n\n Deploy all the Apex classes and custom objects that are in the \"force-app\" directory. The list views, layouts, etc,\n that are associated with the custom objects are also deployed. Both examples are equivalent:\n\n $ sf project deploy start --source-dir force-app/main/default/classes force-app/main/default/objects\n $ sf project deploy start --source-dir force-app/main/default/classes --source-dir \\\n force-app/main/default/objects\n\n Deploy all Apex classes that are in all package directories defined in the \"sfdx-project.json\" file:\n\n $ sf project deploy start --metadata ApexClass\n\n Deploy a specific Apex class; ignore any conflicts between the local project and org (be careful with this flag,\n because it will overwrite the Apex class in the org if there are conflicts!):\n\n $ sf project deploy start --metadata ApexClass:MyApexClass --ignore-conflicts\n\n Deploy specific Apex classes that match a pattern; in this example, deploy Apex classes whose names contain the\n string \"MyApex\". Also ignore any deployment warnings (again, be careful with this flag! You typically want to see\n the warnings):\n\n $ sf project deploy start --metadata 'ApexClass:MyApex*' --ignore-warnings\n\n Deploy a custom object called ExcitingObject that's in the SBQQ namespace:\n\n $ sf project deploy start --metadata CustomObject:SBQQ__ExcitingObject\n\n Deploy all custom objects in the SBQQ namespace by using a wildcard and quotes:\n\n $ sf project deploy start --metadata 'CustomObject:SBQQ__*'\n\n Deploy all custom objects and Apex classes found in all defined package directories (both examples are equivalent):\n\n $ sf project deploy start --metadata CustomObject ApexClass\n $ sf project deploy start --metadata CustomObject --metadata ApexClass\n\n Deploy all Apex classes and a profile that has a space in its name:\n\n $ sf project deploy start --metadata ApexClass --metadata \"Profile:My Profile\"\n\n Deploy all components listed in a manifest:\n\n $ sf project deploy start --manifest path/to/package.xml\n\n Run the tests that aren’t in any managed packages as part of a deployment:\n\n $ sf project deploy start --metadata ApexClass --test-level RunLocalTests\n\n Deploy all metadata formatted files in the \"MDAPI\" directory:\n\n $ sf project deploy start --metadata-dir MDAPI\n\n Deploy all metadata formatted files in the \"MDAPI\" directory; items listed in the MDAPI/destructiveChangesPre.xml\n and MDAPI/destructiveChangesPost.xml manifests are immediately eligible for deletion rather than stored in the\n Recycle Bin:\n\n $ sf project deploy start --metadata-dir MDAPI --purge-on-delete\n\nFLAG DESCRIPTIONS\n -a, --api-version=\u003cvalue\u003e Target API version for the deploy.\n\n Use this flag to override the default API version with the API version of your package.xml file. The default API\n version is the latest version supported by the CLI.\n\n -c, --ignore-conflicts Ignore conflicts and deploy local files, even if they overwrite changes in the org.\n\n This flag applies only to orgs that allow source tracking. It has no effect on orgs that don't allow it, such as\n production orgs.\n\n -d, --source-dir=\u003cvalue\u003e... Path to the local source files to deploy.\n\n The supplied path can be to a single file (in which case the operation is applied to only one file) or to a folder\n (in which case the operation is applied to all metadata types in the directory and its subdirectories).\n\n If you specify this flag, don’t specify --metadata or --manifest.\n\n -g, --ignore-warnings Ignore warnings and allow a deployment to complete successfully.\n\n If you specify this flag, and a warning occurs, the success status of the deployment is set to true. If you don't\n specify this flag, and a warning occurs, then the success status is set to false, and the warning is treated like an\n error.\n\n This flag is useful in a CI environment and your deployment includes destructive changes; if you try to delete a\n component that doesn't exist in the org, you get a warning. In this case, to ensure that the command returns a\n success value of true, specify this flag.\n\n -l, --test-level=NoTestRun|RunSpecifiedTests|RunLocalTests|RunAllTestsInOrg|RunRelevantTests\n\n Deployment Apex testing level.\n\n Valid values are:\n\n - NoTestRun — No tests are run. This test level applies only to deployments to development environments, such as\n sandbox, Developer Edition, or trial orgs. This test level is the default for development environments.\n\n - RunSpecifiedTests — Runs only the tests that you specify with the --tests flag. Code coverage requirements differ\n from the default coverage requirements when using this test level. Executed tests must comprise a minimum of 75%\n code coverage for each class and trigger in the deployment package. This coverage is computed for each class and\n trigger individually and is different than the overall coverage percentage.\n\n - RunLocalTests — All tests in your org are run, except the ones that originate from installed managed and unlocked\n packages. This test level is the default for production deployments that include Apex classes or triggers.\n\n - RunAllTestsInOrg — All tests in your org are run, including tests of managed packages.\n\n - RunRelevantTests (Beta) — Runs only tests that are relevant to the files being deployed. Salesforce automatically\n identifies the relevant tests based on an analysis of the deployment payload and the payload dependencies. For\n fine-grained control, you can also annotate test classes so that they always run in certain conditions. See \"@IsTest\n Annotation\" in the \"Apex Developer Guide\"\n (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_annotation_isTest.htm). Each\n class and trigger in the deployment package must be covered by the executed tests for a minimum of 75% code\n coverage. This coverage is computed for each class and triggers individually and is different than the overall\n coverage percentage.\n\n If you don’t specify a test level, the default behavior depends on the contents of your deployment package and\n target org. For more information, see \"Running Tests in a Deployment\"\n (https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_running_tests.htm) in the\n \"Metadata API Developer Guide\".\n\n -r, --ignore-errors Ignore any errors and don’t roll back deployment.\n\n Never use this flag when deploying to a production org. If you specify it, components without errors are deployed\n and components with errors are skipped, and could result in an inconsistent production org.\n\n -t, --tests=\u003cvalue\u003e... Apex tests to run when --test-level is RunSpecifiedTests.\n\n If a test name contains a space, enclose it in double quotes.\n For multiple test names, use one of the following formats:\n\n - Repeat the flag for multiple test names: --tests Test1 --tests Test2 --tests \"Test With Space\"\n - Separate the test names with spaces: --tests Test1 Test2 \"Test With Space\"\n\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for command to complete and display results.\n\n If the command continues to run after the wait period, the CLI returns control of the terminal window to you and\n returns the job ID. To resume the deployment, run \"sf project deploy resume\". To check the status of the deployment,\n run \"sf project deploy report\".\n\n -x, --manifest=\u003cvalue\u003e Full file path for manifest (package.xml) of components to deploy.\n\n All child components are included. If you specify this flag, don’t specify --metadata or --source-dir.\n\n --async Run the command asynchronously.\n\n The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the\n CLI. To resume the deployment, run \"sf project deploy resume\". To check the status of the deployment, run \"sf\n project deploy report\".\n\n --coverage-formatters=clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...\n\n Format of the code coverage results.\n\n For multiple formatters, repeat the flag for each formatter.\n --coverage-formatters lcov --coverage-formatters clover\n```\n\n_See code: [src/commands/project/deploy/start.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/deploy/start.ts)_\n\n## `sf project deploy validate`\n\nValidate a metadata deployment without actually executing it.\n\n```\nUSAGE\n $ sf project deploy validate -o \u003cvalue\u003e [--json] [--flags-dir \u003cvalue\u003e] [-a \u003cvalue\u003e] [--async] [--concise | --verbose] [-m\n \u003cvalue\u003e...] [-d \u003cvalue\u003e...] [--single-package --metadata-dir \u003cvalue\u003e] [-t \u003cvalue\u003e...] [-l\n RunAllTestsInOrg|RunLocalTests|RunSpecifiedTests|RunRelevantTests] [-w \u003cminutes\u003e] [-g] [--coverage-formatters\n clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...] [--junit]\n [--results-dir \u003cvalue\u003e] [--purge-on-delete -x \u003cvalue\u003e] [--pre-destructive-changes \u003cvalue\u003e ]\n [--post-destructive-changes \u003cvalue\u003e ]\n\nFLAGS\n -a, --api-version=\u003cvalue\u003e Target API version for the validation.\n -g, --ignore-warnings Ignore warnings and allow a deployment to complete successfully.\n -o, --target-org=\u003cvalue\u003e (required) Username or alias of the target org. Not required if the `target-org`\n configuration variable is already set.\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for the command to complete and display results.\n --async Run the command asynchronously.\n --concise Show concise output of the validation result.\n --verbose Show verbose output of the validation result.\n\nSOURCE FORMAT FLAGS\n -d, --source-dir=\u003cvalue\u003e... Path to the local source files to validate for deployment.\n -m, --metadata=\u003cvalue\u003e... Metadata component names to validate for deployment.\n -x, --manifest=\u003cvalue\u003e Full file path for manifest (package.xml) of components to validate for deployment.\n\nTEST FLAGS\n -l, --test-level=\u003coption\u003e [default: RunLocalTests] Deployment Apex testing level.\n \u003coptions: RunAllTestsInOrg|RunLocalTests|RunSpecifiedTests|RunRelevantTests\u003e\n -t, --tests=\u003cvalue\u003e... Apex tests to run when --test-level is RunSpecifiedTests.\n --coverage-formatters=\u003coption\u003e... Format of the code coverage results.\n \u003coptions: clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamci\n ty|text|text-summary\u003e\n --junit Output JUnit test results.\n --results-dir=\u003cvalue\u003e Output directory for code coverage and JUnit results; defaults to the deploy\n ID.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nMETADATA API FORMAT FLAGS\n --metadata-dir=\u003cvalue\u003e Root of directory or zip file of metadata formatted files to deploy.\n --single-package Indicates that the metadata zip file points to a directory structure for a single package.\n\nDELETE FLAGS\n --post-destructive-changes=\u003cvalue\u003e File path for a manifest (destructiveChangesPost.xml) of components to delete\n after the deploy.\n --pre-destructive-changes=\u003cvalue\u003e File path for a manifest (destructiveChangesPre.xml) of components to delete\n before the deploy\n --purge-on-delete Specify that deleted components in the destructive changes manifest file are\n immediately eligible for deletion rather than being stored in the Recycle Bin.\n\nDESCRIPTION\n Validate a metadata deployment without actually executing it.\n\n Use this command to verify whether a deployment will succeed without actually deploying the metadata to your org. This\n command is similar to \"sf project deploy start\", except you're required to run Apex tests, and the command returns a\n job ID rather than executing the deployment. If the validation succeeds, then you pass this job ID to the \"sf project\n deploy quick\" command to actually deploy the metadata. This quick deploy takes less time because it skips running Apex\n tests. The job ID is valid for 10 days from when you started the validation. Validating first is useful if the\n deployment to your production org take several hours and you don’t want to risk a failed deploy.\n\n You must run this command from within a project.\n\n This command doesn't support source-tracking. When you quick deploy with the resulting job ID, the source you deploy\n overwrites the corresponding metadata in your org.\n\n To validate the deployment of multiple metadata components, either set multiple --metadata \u003cname\u003e flags or a single\n --metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double\n quotes. The same syntax applies to --source-dir.\n\n Note: Don't use this command on sandboxes; the command is intended to be used on production orgs. By default,\n sandboxes don't run tests during a deploy. If you want to validate a deployment with tests on a sandbox, use \"sf\n project deploy start --dry-run --test-level RunLocalTests\" instead.\n\nALIASES\n $ sf deploy metadata validate\n\nEXAMPLES\n 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.\n\n Validate the deployment of all source files in the \"force-app\" directory to the default org:\n\n $ sf project deploy validate --source-dir force-app\n\n Validate the deployment of all source files in two directories: \"force-app\" and \"force-app-utils\":\n\n $ sf project deploy validate --source-dir force-app --source-dir force-app-utils\n\n Asynchronously validate the deployment and run all tests in the org with alias \"my-prod-org\"; command immediately\n returns the job ID:\n\n $ sf project deploy validate --source-dir force-app --async --test-level RunAllTestsInOrg --target-org \\\n my-prod-org\n\n Validate the deployment of all components listed in a manifest:\n\n $ sf project deploy validate --manifest path/to/package.xml\n\nFLAG DESCRIPTIONS\n -a, --api-version=\u003cvalue\u003e Target API version for the validation.\n\n Use this flag to override the default API version with the API version of your package.xml file. The default API\n version is the latest version supported by the CLI.\n\n -d, --source-dir=\u003cvalue\u003e... Path to the local source files to validate for deployment.\n\n The supplied path can be to a single file (in which case the operation is applied to only one file) or to a folder\n (in which case the operation is applied to all metadata types in the directory and its subdirectories).\n\n If you specify this flag, don’t specify --metadata or --manifest.\n\n -g, --ignore-warnings Ignore warnings and allow a deployment to complete successfully.\n\n If you specify this flag, and a warning occurs, the success status of the deployment is set to true. If you don't\n specify this flag, and a warning occurs, then the success status is set to false, and the warning is treated like an\n error.\n\n This flag is useful in a CI environment and your deployment includes destructive changes; if you try to delete a\n component that doesn't exist in the org, you get a warning. In this case, to ensure that the command returns a\n success value of true, specify this flag.\n\n -l, --test-level=RunAllTestsInOrg|RunLocalTests|RunSpecifiedTests|RunRelevantTests Deployment Apex testing level.\n\n Valid values are:\n\n - RunSpecifiedTests — Runs only the tests that you specify with the --tests flag. Code coverage requirements differ\n from the default coverage requirements when using this test level. Executed tests must comprise a minimum of 75%\n code coverage for each class and trigger in the deployment package. This coverage is computed for each class and\n trigger individually and is different than the overall coverage percentage.\n\n - RunLocalTests — All tests in your org are run, except the ones that originate from installed managed and unlocked\n packages. This test level is the default.\n\n - RunAllTestsInOrg — All tests in your org are run, including tests of managed packages.\n\n - RunRelevantTests (Beta) — Runs only tests that are relevant to the files being deployed. Salesforce automatically\n identifies the relevant tests based on an analysis of the deployment payload and the payload dependencies. For\n fine-grained control, you can also annotate test classes so that they always run in certain conditions. See \"@IsTest\n Annotation\" in the \"Apex Developer Guide\"\n (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_annotation_isTest.htm). Each\n class and trigger in the deployment package must be covered by the executed tests for a minimum of 75% code\n coverage. This coverage is computed for each class and triggers individually and is different than the overall\n coverage percentage.\n\n If you don’t specify a test level, the default behavior depends on the contents of your deployment package and\n target org. For more information, see \"Running Tests in a Deployment\"\n (https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_running_tests.htm) in the\n \"Metadata API Developer Guide\".\n\n -t, --tests=\u003cvalue\u003e... Apex tests to run when --test-level is RunSpecifiedTests.\n\n If a test name contains a space, enclose it in double quotes.\n For multiple test names, use one of the following formats:\n\n - Repeat the flag for multiple test names: --tests Test1 --tests Test2 --tests \"Test With Space\"\n - Separate the test names with spaces: --tests Test1 Test2 \"Test With Space\"\n\n -w, --wait=\u003cminutes\u003e Number of minutes to wait for the command to complete and display results.\n\n If the command continues to run after the wait period, the CLI returns control of the terminal window to you and\n returns the job ID. To resume watching the validation, run \"sf project deploy resume\". To check the status of the\n validation, run \"sf project deploy report\".\n\n -x, --manifest=\u003cvalue\u003e Full file path for manifest (package.xml) of components to validate for deployment.\n\n All child components are included. If you specify this flag, don’t specify --metadata or --source-dir.\n\n --async Run the command asynchronously.\n\n The command immediately returns the job ID and control of the terminal to you. This way, you can continue to use the\n CLI. To resume watching the validation, run \"sf project deploy resume\". To check the status of the validation, run\n \"sf project deploy report\".\n\n --coverage-formatters=clover|cobertura|html-spa|html|json|json-summary|lcovonly|none|teamcity|text|text-summary...\n\n Format of the code coverage results.\n\n For multiple formatters, repeat the flag for each formatter.\n --coverage-formatters lcov --coverage-formatters clover\n```\n\n_See code: [src/commands/project/deploy/validate.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/deploy/validate.ts)_\n\n## `sf project generate manifest`\n\nCreate a project manifest that lists the metadata components you want to deploy or retrieve.\n\n```\nUSAGE\n $ sf project generate manifest [--json] [--flags-dir \u003cvalue\u003e] [--api-version \u003cvalue\u003e] [-m \u003cvalue\u003e...] [-p \u003cvalue\u003e...] [-n\n \u003cvalue\u003e | -t pre|post|destroy|package] [-c managed|unlocked... --from-org \u003cvalue\u003e] [--excluded-metadata \u003cvalue\u003e...]\n [-d \u003cvalue\u003e]\n\nFLAGS\n -c, --include-packages=\u003coption\u003e... Package types (managed, unlocked) whose metadata is included in the manifest; by\n default, metadata in managed and unlocked packages is excluded. Metadata in\n unmanaged packages is always included.\n \u003coptions: managed|unlocked\u003e\n -d, --output-dir=\u003cvalue\u003e Directory to save the created manifest.\n -m, --metadata=\u003cvalue\u003e... Names of metadata components to include in the manifest.\n -n, --name=\u003cvalue\u003e Name of a custom manifest file to create.\n -p, --source-dir=\u003cvalue\u003e... Paths to the local source files to include in the manifest.\n -t, --type=\u003coption\u003e Type of manifest to create; the type determines the name of the created file.\n \u003coptions: pre|post|destroy|package\u003e\n --api-version=\u003cvalue\u003e Override the api version used for api requests made by this command\n --excluded-metadata=\u003cvalue\u003e... Metadata types to exclude when building a manifest from an org. Specify the name\n of the type, not the name of a specific component.\n --from-org=\u003cvalue\u003e Username or alias of the org that contains the metadata components from which to\n build a manifest.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Create a project manifest that lists the metadata components you want to deploy or retrieve.\n\n Create a manifest from a list of metadata components (--metadata) or from one or more local directories that contain\n source files (--source-dir). You can specify either of these flags, not both.\n\n Use --type to specify the type of manifest you want to create. The resulting manifest files have specific names, such\n as the standard package.xml or destructiveChanges.xml to delete metadata. Valid values for this flag, and their\n respective file names, are:\n\n * package : package.xml (default)\n * pre : destructiveChangesPre.xml\n * post : destructiveChangesPost.xml\n * destroy : destructiveChanges.xml\n\n See https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_deleting_files.htm for\n information about these destructive manifest files.\n\n Use --name to specify a custom name for the generated manifest if the pre-defined ones don’t suit your needs. You can\n specify either --type or --name, but not both.\n\n To include multiple metadata components, either set multiple --metadata \u003cname\u003e flags or a single --metadata flag with\n multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax\n applies to --include-packages and --source-dir.\n\n To build a manifest from the metadata in an org, use the --from-org flag. You can combine --from-org with the\n --metadata flag to include only certain metadata types, or with the --excluded-metadata flag to exclude certain\n metadata types. When building a manifest from an org, the command makes many concurrent API calls to discover the\n metadata that exists in the org. To limit the number of concurrent requests, use the SF_LIST_METADATA_BATCH_SIZE\n environment variable and set it to a size that works best for your org and environment. If you experience timeouts or\n inconsistent manifest contents, then setting this environment variable can improve accuracy. However, the command\n takes longer to run because it sends fewer requests at a time.\n\nALIASES\n $ sf force source manifest create\n\nEXAMPLES\n Create a manifest for deploying or retrieving all Apex classes and custom objects:\n\n $ sf project generate manifest --metadata ApexClass --metadata CustomObject\n\n Create a manifest for deleting the specified Apex class:\n\n $ sf project generate manifest --metadata ApexClass:MyApexClass --type destroy\n\n Create a manifest for deploying or retrieving all the metadata components in the specified local directory; name the\n file myNewManifest.xml:\n\n $ sf project generate manifest --source-dir force-app --name myNewManifest\n\n Create a manifest from the metadata components in the specified org and include metadata in any unlocked packages:\n\n $ sf project generate manifest --from-org test@myorg.com --include-packages unlocked\n\n Create a manifest from specific metadata types in an org:\n\n $ sf project generate manifest --from-org test@myorg.com --metadata ApexClass,CustomObject,CustomLabels\n\n Create a manifest from all metadata components in an org excluding specific metadata types:\n\n $ sf project generate manifest --from-org test@myorg.com --excluded-metadata StandardValueSet\n```\n\n_See code: [src/commands/project/generate/manifest.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/generate/manifest.ts)_\n\n## `sf project list ignored`\n\nCheck your local project package directories for forceignored files.\n\n```\nUSAGE\n $ sf project list ignored [--json] [--flags-dir \u003cvalue\u003e] [-p \u003cvalue\u003e]\n\nFLAGS\n -p, --source-dir=\u003cvalue\u003e File or directory of files that the command checks for foreceignored files.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Check your local project package directories for forceignored files.\n\n When deploying or retrieving metadata between your local project and an org, you can specify the source files you want\n to exclude with a .forceignore file. The .forceignore file structure mimics the .gitignore structure. Each line in\n .forceignore specifies a pattern that corresponds to one or more files. The files typically represent metadata\n components, but can be any files you want to exclude, such as LWC configuration JSON files or tests.\n\nALIASES\n $ sf force source ignored list\n\nEXAMPLES\n List all the files in all package directories that are ignored:\n\n $ sf project list ignored\n\n List all the files in a specific directory that are ignored:\n\n $ sf project list ignored --source-dir force-app\n\n Check if a particular file is ignored:\n\n $ sf project list ignored --source-dir package.xml\n```\n\n_See code: [src/commands/project/list/ignored.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/list/ignored.ts)_\n\n## `sf project reset tracking`\n\nReset local and remote source tracking.\n\n```\nUSAGE\n $ sf project reset tracking -o \u003cvalue\u003e [--json] [--flags-dir \u003cvalue\u003e] [--api-version \u003cvalue\u003e] [-r \u003cvalue\u003e] [-p]\n\nFLAGS\n -o, --target-org=\u003cvalue\u003e (required) Username or alias of the target org. Not required if the `target-org`\n configuration variable is already set.\n -p, --no-prompt Don't prompt for source tracking override confirmation.\n -r, --revision=\u003cvalue\u003e SourceMember revision counter number to reset to.\n --api-version=\u003cvalue\u003e Override the api version used for api requests made by this command\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Reset local and remote source tracking.\n\n WARNING: This command deletes or overwrites all existing source tracking files. Use with extreme caution.\n\n Resets local and remote source tracking so that Salesforce CLI no longer registers differences between your local\n files and those in the org. When you next run 'project deploy preview', Salesforce CLI returns no results, even though\n conflicts might actually exist. Salesforce CLI then resumes tracking new source changes as usual.\n\n Use the --revision flag to reset source tracking to a specific revision number of an org source member. To get the\n revision number, query the SourceMember Tooling API object with the 'data soql' command. For example:\n\n sf data query --query \"SELECT MemberName, MemberType, RevisionCounter FROM SourceMember\" --use-tooling-api\n --target-org my-scratch\n\nALIASES\n $ sf force source tracking reset\n\nEXAMPLES\n Reset source tracking for the org with alias \"my-scratch\":\n\n $ sf project reset tracking --target-org my-scratch\n\n Reset source tracking to revision number 30 for your default org:\n\n $ sf project reset tracking --revision 30\n```\n\n_See code: [src/commands/project/reset/tracking.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/reset/tracking.ts)_\n\n## `sf project retrieve preview`\n\nPreview a retrieval to see what will be retrieved from the org, the potential conflicts, and the ignored files.\n\n```\nUSAGE\n $ sf project retrieve preview -o \u003cvalue\u003e [--json] [--flags-dir \u003cvalue\u003e] [-c] [--concise]\n\nFLAGS\n -c, --ignore-conflicts Don't display conflicts in the preview of the retrieval.\n -o, --target-org=\u003cvalue\u003e (required) Username or alias of the target org. Not required if the `target-org`\n configuration variable is already set.\n --concise Show only the changes that will be retrieved; omits files that are forceignored.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Preview a retrieval to see what will be retrieved from the org, the potential conflicts, and the ignored files.\n\n You must run this command from within a project.\n\n The command outputs a table that describes what will happen if you run the \"sf project retrieve start\" command. The\n table lists the metadata components that will be retrieved and deleted. The table also lists the current conflicts\n between files in your local project and components in the org. Finally, the table lists the files that won't be\n retrieved because they're included in your .forceignore file.\n\n If your org allows source tracking, then this command displays potential conflicts between the org and your local\n project. Some orgs, such as production org, never allow source tracking. Source tracking is enabled by default on\n scratch and sandbox orgs; you can disable source tracking when you create the orgs by specifying the --no-track-source\n flag on the \"sf org create scratch|sandbox\" commands.\n\nALIASES\n $ sf retrieve metadata preview\n\nEXAMPLES\n Preview the retrieve of all changes from your default org:\n\n $ sf project retrieve preview\n\n Preview the retrieve when ignoring any conflicts from an org with alias \"my-scratch\":\n\n $ sf project retrieve preview --ignore-conflicts --target-org my-scratch\n\nFLAG DESCRIPTIONS\n -c, --ignore-conflicts Don't display conflicts in the preview of the retrieval.\n\n This flag applies only to orgs that allow source tracking. It has no effect on orgs that don't allow it, such as\n production orgs.\n```\n\n_See code: [src/commands/project/retrieve/preview.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/retrieve/preview.ts)_\n\n## `sf project retrieve start`\n\nRetrieve metadata from an org to your local project.\n\n```\nUSAGE\n $ sf project retrieve start -o \u003cvalue\u003e [--json] [--flags-dir \u003cvalue\u003e] [-a \u003cvalue\u003e] [-c] [-x \u003cvalue\u003e | -m \u003cvalue\u003e... | -d\n \u003cvalue\u003e...] [-r \u003cvalue\u003e | -n \u003cvalue\u003e... | ] [--single-package -t \u003cvalue\u003e] [-w \u003cvalue\u003e] [-z ] [--zip-file-name\n \u003cvalue\u003e ]\n\nFLAGS\n -a, --api-version=\u003cvalue\u003e Target API version for the retrieve.\n -c, --ignore-conflicts Ignore conflicts and retrieve and save files to your local filesystem, even if they\n overwrite your local changes.\n -d, --source-dir=\u003cvalue\u003e... File paths for source to retrieve from the org.\n -m, --metadata=\u003cvalue\u003e... Metadata component names to retrieve. Wildcards (`*`) supported as long as you use\n quotes, such as `ApexClass:MyClass*`.\n -n, --package-name=\u003cvalue\u003e... Package names to retrieve. Use of this flag is for reference only; don't use it to\n retrieve packaged metadata for development.\n -o, --target-org=\u003cvalue\u003e (required) Username or alias of the target org. Not required if the `target-org`\n configuration variable is already set.\n -r, --output-dir=\u003cvalue\u003e Directory root for the retrieved source files.\n -w, --wait=\u003cvalue\u003e [default: 33 minutes] Number of minutes to wait for the command to complete and display\n results to the terminal window.\n -x, --manifest=\u003cvalue\u003e File path for the manifest (package.xml) that specifies the components to retrieve.\n\nMETADATA API FORMAT FLAGS\n -t, --target-metadata-dir=\u003cvalue\u003e Directory that will contain the retrieved metadata format files or ZIP.\n -z, --unzip Extract all files from the retrieved zip file.\n --single-package Indicates that the zip file points to a directory structure for a single package.\n --zip-file-name=\u003cvalue\u003e File name to use for the retrieved zip file.\n\nGLOBAL FLAGS\n --flags-dir=\u003cvalue\u003e Import flag values from a directory.\n --json Format output as json.\n\nDESCRIPTION\n Retrieve metadata from an org to your local project.\n\n You must run this command from within a project.\n\n Metadata components are retrieved in source format by default. Retrieve them in metadata format by specifying the\n --target-metadata-dir flag, which retrieves the components into a ZIP file in the specified directory.\n\n If your org allows source tracking, then this command tracks the changes in your source. Some orgs, such as production\n orgs, never allow source tracking. Source tracking is enabled by default on scratch and sandbox orgs; you can disable\n source tracking when you create the orgs by specifying the --no-track-source flag on the \"sf org create\n scratch|sandbox\" commands.\n\n To retrieve multiple metadata components, either use multiple --metadata \u003cname\u003e flags or use a single --metadata flag\n with multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same\n syntax applies to --source-dir.\n\nALIASES\n $ sf retrieve metadata\n\nEXAMPLES\n Retrieve all remote changes from your default org:\n\n $ sf project retrieve start\n\n Retrieve the source files in the \"force-app\" directory from an org with alias \"my-scratch\":\n\n $ sf project retrieve start --source-dir force-app --target-org my-scratch\n\n Retrieve all the Apex classes and custom objects whose source is in the \"force-app\" directory. The list views,\n layouts, etc, that are associated with the custom objects are also retrieved. Both examples are equivalent:\n\n $ sf project retrieve start --source-dir force-app/main/default/classes force-app/main/default/objects\n $ sf project retrieve start --source-dir force-app/main/default/classes --source-dir \\\n force-app/main/default/objects\n\n Retrieve all Apex classes that are in all package directories defined in the \"sfdx-project.json\" file:\n\n $ sf project retrieve start --metadata ApexClass\n\n Retrieve a specific Apex class; ignore any conflicts between the local project and org (be careful with this flag,\n because it will overwrite the Apex class source files in your local project if there are conflicts!):\n\n $ sf project retrieve start --metadata ApexClass:MyApexClass --ignore-conflicts\n\n Retrieve specific Apex classes that match a pattern; in this example, retrieve Apex classes whose names contain the\n string \"MyApex\":\n\n $ sf project retrieve start --metadata 'ApexClass:MyApex*'\n\n Retrieve a custom object called ExcitingObject that's in the SBQQ namespace:\n\n $ sf project retrieve start --metadata CustomObject:SBQQ__ExcitingObject\n\n Retrieve all custom objects in the SBQQ namespace by using a wildcard and quotes:\n\n $ sf project retrieve start --metadata 'CustomObject:SBQQ__*'\n\n Retrieve all list views for the Case standard object:\n\n $ sf project retrieve start --metadata 'ListView:Case*'\n\n Retrieve all custom objects and Apex classes found in all defined package directories (both examples are\n equivalent):\n\n $ sf project retrieve start --metadata CustomObject ApexClass\n $ sf project retrieve start --metadata CustomObject --metadata ApexClass\n\n Retrieve all metadata components listed in a manifest:\n\n $ sf project retrieve start --manifest path/to/package.xml\n\n Retrieve metadata from a package:\n\n $ sf project retrieve start --package-name MyPackageName\n\n Retrieve metadata from multiple packages, one of which has a space in its name (both examples are equivalent):\n\n $ sf project retrieve start --package-name Package1 \"PackageName With Spaces\" Package3\n $ sf project retrieve start --package-name Package1 --package-name \"PackageName With Spaces\" --package-name \\\n Package3\n\n Retrieve the metadata components listed in the force-app directory, but retrieve them in metadata format into a ZIP\n file in the \"output\" directory:\n\n $ sf project retrieve start --source-dir force-app --target-metadata-dir output\n\n Retrieve in metadata format and automatically extract the contents into the \"output\" directory:\n\n $ sf project retrieve start --source-dir force-app --target-metadata-dir output --unzip\n\nFLAG DESCRIPTIONS\n -a, --api-version=\u003cvalue\u003e Target API version for the retrieve.\n\n Use this flag to override the default API version, which is the latest version supported the CLI, with the API\n version in your package.xml file.\n\n -c, --ignore-conflicts\n\n Ignore conflicts and retrieve and save files to your local filesystem, even if they overwrite your local changes.\n\n This flag applies only to orgs that allow source tracking. It has no effect on orgs that don't allow it, such as\n production orgs.\n\n -d, --source-dir=\u003cvalue\u003e... File paths for source to retrieve from the org.\n\n The supplied paths can be to a single file (in which case the operation is applied to only one file) or to a folder\n (in which case the operation is applied to all source files in the directory and its subdirectories).\n\n -n, --package-name=\u003cvalue\u003e...\n\n Package names to retrieve. Use of this flag is for reference only; don't use it to retrieve packaged metadata for\n development.\n\n The metadata of the supplied package name(s) will be retrieved into a child directory of the project. The name of\n that child directory matches the name of the package. The retrieved metadata is meant for your reference only, don't\n add it to a source control system for development and deployment. For package development, retrieve the metadata\n using a manifest (`--manifest` flag) or by targeting a source controlled package directory within your project\n (`--source-dir` flag).\n\n -r, --output-dir=\u003cvalue\u003e Directory root for the retrieved source files.\n\n The root of the directory structure into which the source files are retrieved.\n If the target directory matches one of the package directories in your sfdx-project.json file, the command fails.\n Running the command multiple times with the same target adds new files and overwrites existing files.\n\n -w, --wait=\u003cvalue\u003e Number of minutes to wait for the command to complete and display results to the terminal window.\n\n If the command continues to run after the wait period, the CLI returns control of the terminal window to you.\n\n -x, --manifest=\u003cvalue\u003e File path for the manifest (package.xml) that specifies the components to retrieve.\n\n If you specify this flag, don’t specify --metadata or --source-dir.\n```\n\n_See code: [src/commands/project/retrieve/start.ts](https://github.com/salesforcecli/plugin-deploy-retrieve/blob/3.24.52/src/commands/project/retrieve/start.ts)_\n\n\u003c!-- commandsstop --\u003e\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsalesforcecli%2Fplugin-deploy-retrieve","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsalesforcecli%2Fplugin-deploy-retrieve","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsalesforcecli%2Fplugin-deploy-retrieve/lists"}