|
1 | 1 | { |
2 | | - "description": "deploy source to an org Use this command to deploy source (metadata that’s in source format) to an org.\nTo take advantage of change tracking with scratch orgs, use \"sfdx force:source:push\".\nTo deploy metadata that’s in metadata format, use \"sfdx force:mdapi:deploy\".\n\nThe source you deploy overwrites the corresponding metadata in your org. This command does not attempt to merge your source with the versions in your org.\n\nTo run the command asynchronously, set --wait to 0, which immediately returns the job ID. This way, you can continue to use the CLI.\nTo check the status of the job, use force:source:deploy:report.\n\nIf the comma-separated list you’re supplying contains spaces, enclose the entire comma-separated list in one set of double quotes. On Windows, if the list contains commas, also enclose the entire list in one set of double quotes.\n", |
| 2 | + "description": "deploy source to an org\nUse this command to deploy source (metadata that’s in source format) to an org.\nTo take advantage of change tracking with scratch orgs, use \"sfdx force:source:push\".\nTo deploy metadata that’s in metadata format, use \"sfdx force:mdapi:deploy\".\n\nThe source you deploy overwrites the corresponding metadata in your org. This command does not attempt to merge your source with the versions in your org.\n\nTo run the command asynchronously, set --wait to 0, which immediately returns the job ID. This way, you can continue to use the CLI.\nTo check the status of the job, use force:source:deploy:report.\n\nIf the comma-separated list you’re supplying contains spaces, enclose the entire comma-separated list in one set of double quotes. On Windows, if the list contains commas, also enclose the entire list in one set of double quotes.\n", |
3 | 3 | "examples": [ |
4 | 4 | "To deploy the source files in a directory:\n\t $ sfdx force:source:deploy -p path/to/source", |
5 | 5 | "To deploy a specific Apex class and the objects whose source is in a directory: \n\t$ sfdx force:source:deploy -p \"path/to/apex/classes/MyClass.cls,path/to/source/objects\"", |
|
27 | 27 | "validateDeployRequestId": "deploy request ID of the validated deployment to run a Quick Deploy", |
28 | 28 | "soapDeploy": "deploy metadata with SOAP API instead of REST API" |
29 | 29 | }, |
| 30 | + "flagsLong": { |
| 31 | + "sourcePath": [ |
| 32 | + "A comma-separated list of paths to the local source files to deploy. The supplied paths can be to a single file (in which case the operation is applied to only one file) or to a folder (in which case the operation is applied to all metadata types in the directory and its sub-directories).", |
| 33 | + "If you specify this parameter, don’t specify --manifest or --metadata." |
| 34 | + ], |
| 35 | + "manifest": [ |
| 36 | + "The complete path for the manifest (package.xml) file that specifies the components to deploy. All child components are included.", |
| 37 | + "If you specify this parameter, don’t specify --metadata or --sourcepath." |
| 38 | + ], |
| 39 | + "metadata": [ |
| 40 | + "A comma-separated list of names of metadata components to deploy to the org.", |
| 41 | + "If you specify this parameter, don’t specify --manifest or --sourcepath." |
| 42 | + ], |
| 43 | + "wait": "Number of minutes to wait for the command to complete and display results to the terminal window. If the command continues to run after the wait period, the CLI returns control of the terminal window to you. ", |
| 44 | + "checkonly": [ |
| 45 | + "Validates the deployed metadata and runs all Apex tests, but prevents the deployment from being saved to the org.", |
| 46 | + "If you change a field type from Master-Detail to Lookup or vice versa, that change isn’t supported when using the --checkonly parameter to test a deployment (validation). This kind of change isn’t supported for test deployments to avoid the risk of data loss or corruption. If a change that isn’t supported for test deployments is included in a deployment package, the test deployment fails and issues an error.", |
| 47 | + "If your deployment package changes a field type from Master-Detail to Lookup or vice versa, you can still validate the changes prior to deploying to Production by performing a full deployment to another test Sandbox. A full deployment includes a validation of the changes as part of the deployment process.", |
| 48 | + "Note: A Metadata API deployment that includes Master-Detail relationships deletes all detail records in the Recycle Bin in the following cases.", |
| 49 | + "1. For a deployment with a new Master-Detail field, soft delete (send to the Recycle Bin) all detail records before proceeding to deploy the Master-Detail field, or the deployment fails. During the deployment, detail records are permanently deleted from the Recycle Bin and cannot be recovered.", |
| 50 | + "2. For a deployment that converts a Lookup field relationship to a Master-Detail relationship, detail records must reference a master record or be soft-deleted (sent to the Recycle Bin) for the deployment to succeed. However, a successful deployment permanently deletes any detail records in the Recycle Bin." |
| 51 | + ], |
| 52 | + "testLevel": [ |
| 53 | + "Specifies which level of deployment tests to run. Valid values are:", |
| 54 | + " NoTestRun—No tests are run. This test level applies only to deployments to development environments, such as sandbox, Developer Edition, or trial orgs. This test level is the default for development environments.", |
| 55 | + " RunSpecifiedTests—Runs only the tests that you specify in the --runtests option. Code coverage requirements differ from the default coverage requirements when using this test level. Executed tests must comprise a minimum of 75% code coverage for each class and trigger in the deployment package. This coverage is computed for each class and trigger individually and is different than the overall coverage percentage.", |
| 56 | + " RunLocalTests—All tests in your org are run, except the ones that originate from installed managed packages. This test level is the default for production deployments that include Apex classes or triggers.", |
| 57 | + " RunAllTestsInOrg—All tests in your org are run, including tests of managed packages.", |
| 58 | + "If you don’t specify a test level, the default behavior depends on the contents of your deployment package. For more information, see “Running Tests in a Deployment” in the Metadata API Developer Guide." |
| 59 | + ], |
| 60 | + "runTests": "Lists the Apex classes containing the deployment tests to run. Use this parameter when you set --testlevel to RunSpecifiedTests.", |
| 61 | + "ignoreErrors": "Ignores the deploy errors, and continues with the deploy operation. The default is false. Keep this parameter set to false when deploying to a production org. If set to true, components without errors are deployed, and components with errors are skipped.", |
| 62 | + "ignoreWarnings": "If a warning occurs and ignoreWarnings is set to true, the success field in DeployMessage is true. When ignoreWarnings is set to false, success is set to false, and the warning is treated like an error.", |
| 63 | + "validateDeployRequestId": [ |
| 64 | + "Specifies the ID of a package with recently validated components to run a Quick Deploy. Deploying a validation helps you shorten your deployment time because tests aren’t rerun. If you have a recent successful validation, you can deploy the validated components without running tests. A validation doesn’t save any components in the org. You use a validation only to check the success or failure messages that you would receive with an actual deployment. To validate your components, add the -c | --checkonly flag when you run \"sfdx force:mdapi:deploy\". This flag sets the checkOnly=\"true\" parameter for your deployment. Before deploying a recent validation, ensure that the following requirements are met:", |
| 65 | + " 1. The components have been validated successfully for the target environment within the last 10 days.", |
| 66 | + " 2. As part of the validation, Apex tests in the target org have passed.", |
| 67 | + " 3. Code coverage requirements are met.", |
| 68 | + " - If all tests in the org or all local tests are run, overall code coverage is at least 75%, and Apex triggers have some coverage.", |
| 69 | + " - If specific tests are run with the RunSpecifiedTests test level, each class and trigger that was deployed is covered by at least 75% individually." |
| 70 | + ] |
| 71 | + }, |
30 | 72 | "MissingRequiredParam": "Missing one of the following parameters: %s", |
31 | 73 | "checkOnlySuccess": "Successfully validated the deployment. %s components deployed and %s tests run.\nUse the --verbose parameter to see detailed output.", |
32 | 74 | "MissingDeployId": "No deploy ID was provided or found in deploy history", |
|
0 commit comments