@salesforce/plugin-deploy-retrieve 1.8.3 → 1.8.5-beta.1

package/messages/deploy.metadata.preview.md

@@ -6,7 +6,7 @@ Preview a deployment to see what will deploy to the org, the potential conflicts
 
 You must run this command from within a project.
 
-The command outputs a table that describes what will happen if you run the "sf deploy metadata" 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.
+The command outputs a table that describes what will happen if you run the "<%= config.bin %> 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 considers conflicts between the org and local. Some orgs, such as production orgs, never allow source tracking. Use the "--no-track-source" flag when you create a scratch or sandbox org to disable source tracking.
 
@@ -14,7 +14,7 @@ To preview the deployment of multiple metadata components, either set multiple -
 
 # 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 deploy metadata" for more examples that you can adapt for previewing.
+- 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 "<%= config.bin %> 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:
 
@@ -36,6 +36,10 @@ To preview the deployment of multiple metadata components, either set multiple -
 
 Login username or alias for the target org.
 
+# flags.only-ignored.summary
+
+Preview files to be ignored in a deployment.
+
 # flags.target-org.description
 
 Overrides your default org.
@@ -90,4 +94,4 @@ There are changes in the org that conflict with the local changes you're trying
 
 - To overwrite the remote changes, rerun this command with the --ignore-conflicts flag.
 
-- To overwrite the local changes, run the "sf retrieve metadata" command with the --ignore-conflicts flag.
+- To overwrite the local changes, run the "sf project retrieve start" command with the --ignore-conflicts flag.

package/messages/deploy.metadata.quick.md

@@ -4,7 +4,7 @@ Quickly deploy a validated deployment to an org.
 
 # description
 
-Before you run this command, first create a validated deployment with the "sf deploy metadata 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.
+Before you run this command, first create a validated deployment with the "<%= config.bin %> 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.
 
@@ -36,13 +36,21 @@ 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.
 
+# flags.api-version.summary
+
+Target API version for the deploy.
+
+# flags.api-version.description
+
+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.
+
 # flags.wait.summary
 
 Number of minutes to wait for the command to complete and display results.
 
 # flags.wait.description
 
-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 deploy metadata resume". To check the status of the deploy, run "sf deploy metadata report".
+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 "<%= config.bin %> project deploy resume". To check the status of the deploy, run "<%= config.bin %> project deploy report".
 
 # flags.verbose.summary
 
@@ -58,7 +66,7 @@ Run the command asynchronously.
 
 # flags.async.description
 
-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 deploy metadata resume". To check the status of the deploy, run "sf deploy metadata report".
+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 "<%= config.bin %> project deploy resume". To check the status of the deploy, run "<%= config.bin %> project deploy report".
 
 # flags.target-org.summary
 

package/messages/deploy.metadata.report.md

@@ -18,6 +18,14 @@ Run this command by either passing it a job ID or specifying the --use-most-rece
 
       <%= config.bin %> <%= command.id %> --use-most-recent
 
+# flags.target-org.summary
+
+Login username or alias for the target org.
+
+# flags.api-version.summary
+
+API version to use
+
 # flags.job-id.summary
 
 Job ID of the deploy operation you want to check the status of.
@@ -26,10 +34,10 @@ 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 deploy metadata
-- sf deploy metadata validate
-- sf deploy metadata quick
-- sf deploy metadata cancel
+- <%= config.bin %> project deploy start
+- <%= config.bin %> project deploy validate
+- <%= config.bin %> project deploy quick
+- <%= config.bin %> project deploy cancel
 
 The job ID is valid for 10 days from when you started the deploy operation.
 
@@ -40,3 +48,15 @@ Use the job ID of the most recent deploy operation.
 # flags.use-most-recent.description
 
 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.
+
+# flags.junit
+
+output JUnit test results
+
+# flags.coverage-formatters
+
+format of the code coverage results
+
+# flags.results-dir
+
+output directory for code coverage and JUnit results; defaults to the deploy ID

package/messages/deploy.metadata.resume.md

@@ -26,10 +26,10 @@ 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 deploy metadata
-- sf deploy metadata validate
-- sf deploy metadata quick
-- sf deploy metadata cancel
+- <%= config.bin %> project deploy start
+- <%= config.bin %> project deploy validate
+- <%= config.bin %> project deploy quick
+- <%= config.bin %> project deploy cancel
 
 The job ID is valid for 10 days from when you started the deploy operation.
 
@@ -47,7 +47,7 @@ Number of minutes to wait for the command to complete and display results.
 
 # flags.wait.description
 
-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 deploy metadata report".
+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 "<%= config.bin %> project deploy report".
 
 # flags.verbose.summary
 
@@ -60,3 +60,15 @@ Show concise output of the deploy operation result.
 # error.DeployNotResumable
 
 Job ID %s is not resumable with status %s.
+
+# flags.junit
+
+output JUnit test results
+
+# flags.coverage-formatters
+
+format of the code coverage results
+
+# flags.results-dir
+
+output directory for code coverage and JUnit results; defaults to the deploy ID

package/messages/deploy.metadata.validate.md

@@ -4,7 +4,7 @@ Validate a metadata deployment without actually executing it.
 
 # description
 
-Use this command to verify whether a deployment will succeed without actually deploying the metadata to your org. This command is similar to "sf deploy metadata", 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 deploy metadata 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.
+Use this command to verify whether a deployment will succeed without actually deploying the metadata to your org. This command is similar to "<%= config.bin %> 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 "<%= config.bin %> 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.
 
@@ -14,7 +14,7 @@ To validate the deployment of multiple metadata components, either set multiple
 
 # examples
 
-- NOTE: These examples focus on validating large deployments. See the help for "sf deploy metadata" for examples of deploying smaller sets of metadata which you can also use to validate.
+- NOTE: These examples focus on validating large deployments. See the help for "<%= config.bin %> 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 a directory to the default org:
 
@@ -72,7 +72,7 @@ Number of minutes to wait for the command to complete and display results.
 
 # flags.wait.description
 
-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 deploy metadata resume". To check the status of the validation, run "sf deploy metadata report".
+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 "<%= config.bin %> project deploy resume". To check the status of the validation, run "<%= config.bin %> project deploy report".
 
 # flags.manifest.summary
 
@@ -112,7 +112,7 @@ Run the command asynchronously.
 
 # flags.async.description
 
-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 deploy metadata resume". To check the status of the validation, run "sf deploy metadata report".
+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 "<%= config.bin %> project deploy resume". To check the status of the validation, run "<%= config.bin %> project deploy report".
 
 # flags.metadata-dir.summary
 
@@ -126,6 +126,10 @@ Indicates that the metadata zip file points to a directory structure for a singl
 
 Successfully validated the deployment (%s).
 
+# info.suggestedQuickDeploy
+
+Run "%s project deploy quick --job-id %s" to execute this deploy
+
 # error.FailedValidation
 
-Falied to validate the deployment (%s).
+Failed to validate the deployment (%s).

package/messages/manifest.create.md

@@ -0,0 +1,61 @@
+# description
+
+create a project manifest that lists the metadata components you want to deploy or retrieve
+Create a manifest from a list of metadata components (--metadata) or from one or more local directories that contain source files (--source-path). You can specify either of these parameters, not both.
+
+Use --manifest-type to specify the type of manifest you want to create. The resulting manifest files have specific names, such as the standard package.xml or destructiveChanges.xml to delete metadata. Valid values for this parameter, and their respective file names, are:
+
+package : package.xml (default)
+pre : destructiveChangesPre.xml
+post : destructiveChangesPost.xml
+destroy : destructiveChanges.xml
+
+See https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_deploy_deleting_files.htm for information about these destructive manifest files.
+
+Use --manifest-name to specify a custom name for the generated manifest if the pre-defined ones don’t suit your needs. You can specify either --manifest-type or --manifest-name, but not both.
+
+# examples
+
+- $ <%= config.bin %> <%= command.id %> -m ApexClass
+
+- $ <%= config.bin %> <%= command.id %> -m ApexClass:MyApexClass --manifest-type destroy
+
+- $ <%= config.bin %> <%= command.id %> --source-path force-app --manifest-name myNewManifest
+
+- $ <%= config.bin %> <%= command.id %> --from-org test@myorg.com --include-packages unlocked
+
+# flags.include-packages
+
+comma-separated list of package types (managed, unlocked) whose metadata is included in the manifest; by default, metadata in packages is ignored
+
+# flags.from-org
+
+username or alias of the org that contains the metadata components from which to build a manifest
+
+# flags.manifest-type
+
+type of manifest to create; the type determines the name of the created file
+
+# flags.manifest-name
+
+name of a custom manifest file to create
+
+# flags.output-dir
+
+directory to save the created manifest
+
+# flags.source-path
+
+comma-separated list of paths to the local source files to include in the manifest
+
+# flags.metadata
+
+comma-separated list of names of metadata components to include in the manifest
+
+# success
+
+successfully wrote %s
+
+# successOutputDir
+
+successfully wrote %s to %s

package/messages/retrieve.metadata.md

@@ -157,7 +157,7 @@ There are changes in your local files that conflict with the org changes you're
 
 - To overwrite the local changes, rerun this command with the --ignore-conflicts flag.
 
-- To overwrite the remote changes, run the "sf deploy metadata" command with the --ignore-conflicts flag.
+- To overwrite the remote changes, run the "sf project deploy start" command with the --ignore-conflicts flag.
 
 # info.WroteZipFile
 

package/messages/retrieve.metadata.preview.md

@@ -6,7 +6,7 @@ Preview a retrieval to see what will be retrieved from the org, the potential co
 
 You must run this command from within a project.
 
-The command outputs a table that describes what will happen if you run the "sf retrieve metadata" command. The table lists the metadata components that will be retrieved 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 retrieved because they're included in your .forceignore file.
+The command outputs a table that describes what will happen if you run the "<%= config.bin %> project retrieve start" command. The table lists the metadata components that will be retrieved 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 retrieved because they're included in your .forceignore file.
 
 If your org allows source tracking, then this command considers conflicts between the org and local. Some orgs, such as production orgs, never allow source tracking. Use the "--no-track-source" flag when you create a scratch or sandbox org to disable source tracking.
 
@@ -54,6 +54,6 @@ There are local changes that conflict with the remote changes that would be retr
 
 # error.Conflicts.Actions
 
-- To overwrite the remote changes, run the "sf deploy metadata" command with the --ignore-conflicts flag.
+- To overwrite the remote changes, run the "project deploy start" command with the --ignore-conflicts flag.
 
-- To overwrite the local changes, run the "sf retrieve metadata" command with the --ignore-conflicts flag.
+- To overwrite the local changes, run the "project retrieve start" command with the --ignore-conflicts flag.