Skip to content

hardis:project:deploy:sources:dx

Description

Deploy SFDX source to org, following deploymentPlan in .sfdx-hardis.yml

In case of errors, tips to fix them will be included within the error messages.

Quick Deploy

In case Pull Request comments are configured on the project, Quick Deploy will try to be used (equivalent to button Quick Deploy)

If you do not want to use QuickDeploy, define variable SFDX_HARDIS_QUICK_DEPLOY=false

Delta deployments

To activate delta deployments, define property useDeltaDeployment: true in config/.sfdx-hardis.yml.

This will activate delta deployments only between minor and major branches (major to major remains full deployment mode)

If you want to force the delta deployment into major orgs (ex: preprod to prod), this is not recommended but you can use env variable ALWAYS_ENABLE_DELTA_DEPLOYMENT=true

Dynamic deployment items / Overwrite management

If necessary,you can define the following files (that supports wildcards *):

  • manifest/package-no-overwrite.xml: Every element defined in this file will be deployed only if it is not existing yet in the target org (can be useful with ListView for example, if the client wants to update them directly in production org)
  • manifest/packageXmlOnChange.xml: Every element defined in this file will not be deployed if it already has a similar definition in target org (can be useful for SharingRules for example)

See Overwrite management documentation

Deployment plan

If you need to deploy in multiple steps, you can define a property deploymentPlan in .sfdx-hardis.yml.

  • If a file manifest/package.xml is found, it will be placed with order 0 in the deployment plan
  • If a file manifest/destructiveChanges.xml is found, it will be executed as --postdestructivechanges
  • If env var SFDX_HARDIS_DEPLOY_IGNORE_SPLIT_PACKAGES is defined as false , split of package.xml will be applied

Example:

deploymentPlan:
  packages:
    - label: Deploy Flow-Workflow
      packageXmlFile: manifest/splits/packageXmlFlowWorkflow.xml
      order: 6
    - label: Deploy SharingRules - Case
      packageXmlFile: manifest/splits/packageXmlSharingRulesCase.xml
      order: 30
      waitAfter: 30

Packages installation

You can define a list of package to install during deployments using property installedPackages

  • If INSTALL_PACKAGES_DURING_CHECK_DEPLOY is defined as true (or installPackagesDuringCheckDeploy: true in .sfdx-hardis.yml), packages will be installed even if the command is called with --check mode
  • You can automatically update this property by listing all packages installed on an org using command sfdx hardis:org:retrieve:packageconfig

Example:

installedPackages:
  - Id: 0A35r0000009EtECAU
    SubscriberPackageId: 033i0000000LVMYAA4
    SubscriberPackageName: Marketing Cloud
    SubscriberPackageNamespace: et4ae5
    SubscriberPackageVersionId: 04t6S000000l11iQAA
    SubscriberPackageVersionName: Marketing Cloud
    SubscriberPackageVersionNumber: 236.0.0.2
    installOnScratchOrgs: true                  // true or false depending you want to install this package when creating a new scratch org
    installDuringDeployments: true              // set as true to install package during a deployment using sfdx hardis:project:deploy:sources:dx
    installationkey: xxxxxxxxxxxxxxxxxxxx       // if the package has a password, write it in this property
    - Id: 0A35r0000009F9CCAU
    SubscriberPackageId: 033b0000000Pf2AAAS
    SubscriberPackageName: Declarative Lookup Rollup Summaries Tool
    SubscriberPackageNamespace: dlrs
    SubscriberPackageVersionId: 04t5p000001BmLvAAK
    SubscriberPackageVersionName: Release
    SubscriberPackageVersionNumber: 2.15.0.9
    installOnScratchOrgs: true
    installDuringDeployments: true

Deployment pre or post commands

You can define command lines to run before or after a deployment

If the commands are not the same depending on the target org, you can define them into config/branches/.sfdx-hardis-BRANCHNAME.yml instead of root config/.sfdx-hardis.yml

Example:

commandsPreDeploy:
  - id: knowledgeUnassign
    label: Remove KnowledgeUser right to the user who has it
    command: sf data update record --sobject User --where "UserPermissionsKnowledgeUser='true'" --values "UserPermissionsKnowledgeUser='false'" --json
  - id: knowledgeAssign
    label: Assign Knowledge user to the deployment user
    command: sf data update record --sobject User --where "Username='deploy.github@myclient.com'" --values "UserPermissionsKnowledgeUser='true'" --json
commandsPostDeploy:
  - id: knowledgeUnassign
    label: Remove KnowledgeUser right to the user who has it
    command: sf data update record --sobject User --where "UserPermissionsKnowledgeUser='true'" --values "UserPermissionsKnowledgeUser='false'" --json
  - id: knowledgeAssign
    label: Assign Knowledge user to desired username
    command: sf data update record --sobject User --where "Username='admin-yser@myclient.com'" --values "UserPermissionsKnowledgeUser='true'" --json

Automated fixes post deployments

List view with scope Mine

If you defined a property listViewsToSetToMine in your .sfdx-hardis.yml, related ListViews will be set to Mine ( see command https://sfdx-hardis.cloudity.com/hardis/org/fix/listviewmine/ )

Example:

listViewsToSetToMine:
  - "Operation__c:MyCurrentOperations"
  - "Operation__c:MyFinalizedOperations"
  - "Opportunity:Default_Opportunity_Pipeline"
  - "Opportunity:MyCurrentSubscriptions"
  - "Opportunity:MySubscriptions"
  - "Account:MyActivePartners"

Troubleshooting: if you need to fix ListViews with mine from an alpine-linux based docker image, use this workaround in your dockerfile:

# Do not use puppeteer embedded chromium
RUN apk add --update --no-cache chromium
ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD="true"
ENV CHROMIUM_PATH="/usr/bin/chromium-browser"
ENV PUPPETEER_EXECUTABLE_PATH="$\{CHROMIUM_PATH}" // remove \ before {

If you need to increase the deployment waiting time (force:source:deploy --wait arg), you can define env variable SFDX_DEPLOY_WAIT_MINUTES

If you need notifications to be sent using the current Pull Request and not the one just merged (see use case), define env variable SFDX_HARDIS_DEPLOY_BEFORE_MERGE=true

Parameters

Name Type Description Default Required Options
apiversion option override the api version used for api requests made by this command
check
-c		 boolean Only checks the deployment, there is no impact on target org
debug
-d		 boolean Activate debug mode (more logs)
delta boolean Applies sfdx-git-delta to package.xml before other deployment processes
json boolean format output as json
loglevel option logging level for this command invocation warn trace
debug
info
warn
error
fatal
packagexml
-p		 option Path to package.xml containing what you want to deploy in target org
runtests
-r		 option If testlevel=RunSpecifiedTests, please provide a list of classes.
If testlevel=RunRepositoryTests, can contain a regular expression to keep only class names matching it. If not set, will run all test classes found in the repo.
skipauth boolean Skip authentication check when a default username is required
targetusername
-u		 option username or alias for the target org; overrides default target org
testlevel
-l		 option Level of tests to validate deployment. RunRepositoryTests auto-detect and run all repository test classes NoTestRun
RunSpecifiedTests
RunRepositoryTests
RunRepositoryTestsExceptSeeAllData
RunLocalTests
RunAllTestsInOrg
websocket option Websocket host:port for VsCode SFDX Hardis UI integration

Examples

$ sfdx hardis:project:deploy:sources:dx

$ sfdx hardis:project:deploy:sources:dx --check

$ sfdx hardis:project:deploy:sources:dx --check --testlevel RunRepositoryTests

$ sfdx hardis:project:deploy:sources:dx --check --testlevel RunRepositoryTests --runtests '^(?!FLI|MyPrefix).*'

$ sfdx hardis:project:deploy:sources:dx --check --testlevel RunRepositoryTestsExceptSeeAllData