@salesforce/plugin-deploy-retrieve 3.2.24 → 3.2.26

package/oclif.manifest.json

@@ -202,7 +202,7 @@
           "deprecateAliases": true,
           "name": "output-dir",
           "summary": "Output directory to store the Metadata API–formatted files in.",
-          "default": "metadataPackage_1709591623974",
+          "default": "metadataPackage_1709660846060",
           "hasDynamicHelp": false,
           "multiple": false,
           "type": "option"
@@ -851,7 +851,7 @@
       ],
       "args": {},
       "deprecateAliases": true,
-      "description": "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.\n\nExecuting 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.\n\nThis command doesn't support source-tracking. The source you deploy overwrites the corresponding metadata in your org. This command doesn’t attempt to merge your source with the versions in your org.",
+      "description": "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.\n\nExecuting 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.\n\nThis command doesn't support source-tracking. The source you deploy overwrites the corresponding metadata in your org. This command doesn’t attempt to merge your source with the versions in your org.\n\nNote: Don't use this command on sandboxes; the command is intended to be used on production orgs.  By default, sandboxes don't run tests during a deploy. Use `sf project deploy start` instead.",
       "examples": [
         "Run a quick deploy to your default org using a job ID:\n<%= config.bin %> <%= command.id %> --job-id 0Af0x000017yLUFCA2",
         "Asynchronously run a quick deploy of the most recently validated deployment to an org with alias \"my-prod-org\":\n<%= config.bin %> <%= command.id %> --async --use-most-recent --target-org my-prod-org"
@@ -1736,7 +1736,7 @@
       ],
       "args": {},
       "deprecateAliases": true,
-      "description": "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.\n\nYou must run this command from within a project.\n\nThis command doesn't support source-tracking. When you quick deploy with the resulting job ID, the source you deploy overwrites the corresponding metadata in your org.\n\nTo validate the deployment of multiple metadata components, either set multiple --metadata <name> flags or a single --metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax applies to --manifest and --source-dir.",
+      "description": "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.\n\nYou must run this command from within a project.\n\nThis command doesn't support source-tracking. When you quick deploy with the resulting job ID, the source you deploy overwrites the corresponding metadata in your org.\n\nTo validate the deployment of multiple metadata components, either set multiple --metadata <name> flags or a single --metadata flag with multiple names separated by spaces. Enclose names that contain spaces in one set of double quotes. The same syntax applies to --manifest and --source-dir.\n\nNote: Don't use this command on sandboxes; the command is intended to be used on production orgs. By default, sandboxes don't run tests during a deploy.  If you want to validate a deployment with tests on a sandbox, use \"sf project deploy start --dry-run --test-level RunLocalTests\" instead.",
       "examples": [
         "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 the \"force-app\" directory to the default org:\n<%= config.bin %> <%= command.id %> --source-dir force-app",
@@ -2816,5 +2816,5 @@
       ]
     }
   },
-  "version": "3.2.24"
+  "version": "3.2.26"
 }

package/package.json

@@ -1,7 +1,7 @@
 {
     "name": "@salesforce/plugin-deploy-retrieve",
     "description": "deploy and retrieve commands for sf",
-    "version": "3.2.24",
+    "version": "3.2.26",
     "author": "Salesforce",
     "bugs": "https://github.com/forcedotcom/cli/issues",
     "dependencies": {
@@ -19,7 +19,7 @@
     "devDependencies": {
         "@oclif/plugin-command-snapshot": "^5.0.9",
         "@salesforce/cli-plugins-testkit": "^5.1.9",
-        "@salesforce/dev-scripts": "^8.4.1",
+        "@salesforce/dev-scripts": "^8.4.2",
         "@salesforce/plugin-command-reference": "^3.0.65",
         "@salesforce/plugin-source": "^2.11.4",
         "@salesforce/source-testkit": "^2.1.99",
@@ -252,7 +252,7 @@
     "exports": "./lib/index.js",
     "type": "module",
     "sfdx": {
-        "publicKeyUrl": "https://developer.salesforce.com/media/salesforce-cli/security/@salesforce/plugin-deploy-retrieve/3.2.24.crt",
-        "signatureUrl": "https://developer.salesforce.com/media/salesforce-cli/security/@salesforce/plugin-deploy-retrieve/3.2.24.sig"
+        "publicKeyUrl": "https://developer.salesforce.com/media/salesforce-cli/security/@salesforce/plugin-deploy-retrieve/3.2.26.crt",
+        "signatureUrl": "https://developer.salesforce.com/media/salesforce-cli/security/@salesforce/plugin-deploy-retrieve/3.2.26.sig"
     }
 }