sfpowerscripts:orchestrator is a group of commands (or topic in the CLI parlance) that enables one to work with multiple packages in a mono-repo through the development lifecycle or stages. The current version of the orchestrator features these commands
You should use the orchestrator when you have two or more packages ( source/unlocked/data) and mono-repo is your preferred approach.
No, orchestrator is built around our experience when dealing with a very large org with multiple packages. We have added lot of "modifiers" that can be added as to each individual package which can be used to control the test/build/deploy behavior of a package declaratively. If these options are not sufficient, we are happy to help by adding additional options or you could script yourselves using the standalone sfpowerscripts commands. The current "modifiers" for orchestrator as follows, however each individual packages supports more modifiers, which is detailed here.
{​"skipDeployOnOrgs": ["org1","org2"], // List of org's that this package should be skipped during deployment"skipCoverageValidation":<boolean> //default:false, skip apex coverage validation during validation phase,"ignoreOnStage": [ //Skip this package during the below orchestrator commands"prepare","validate"]}
No, the above are the modifiers for the orchestrator commands, irrespective if you use orchestrator or individual commands, following modifiers are available for every packages
{"aliasfy": <boolean>, // Only for source packages, allows to deploy a subfolder whose name matches the alias of the org when using deploy command"isOptimizedDeployment": <boolean> // default:true for source packages, Utilizes the apex classes in the package for deployment,"skipTesting":<boolean> //default:false, skip apex testing during installation of source package to a sandbox"skipCoverageValidation":<boolean> //default:false, skip apex coverage validation during validation phase,"destructiveChangePath:<path> // only for source, if enabled, this will be applied before the package is deployed"assignPermSetsPreDeployment: ["","",]"assignPermSetsPostDeployment: ["","",]"preDeploymentScript":<path> //All Packages"postDeploymentScript:<path> // All packages"reconcileProfiles:<boolean> //default:true Source Packages}
Sometimes, due to certain platform errors, some metadata components need to be ignored during quickbuild or validate or any other stages. sfpowerscripts offer you an easy mechanism, which allows to switch .forceignore files depending on the stage.
Add this entry to your sfdx-project.json and as in the example below, mention the path to different files that need to be used for different stages
"plugins": {"sfpowerscripts": {"ignoreFiles": {"prepare": ".forceignore","validate": ".forceignore","quickbuild": "forceignores/.buildignore","build": "forceignores/.validationignore"}}
Excluding prepare and validate, the other orchestrator commands such as quickbuild, build and deploy operate on a given artifact directory (that contains sfpowerscripts artifacts) and a sfdx-project.json
Here is a sample model that you could use on simple programs
Yes, head to the repo https://github.com/dxatscale/easy-spaces-lwc for examples on how to use these commands with GitHub actions
Yes, you could use the ignoreOnStage
descriptor to mark which packages should be skipped by the lifecycle commands.
Not yet we are working on it, currently deploy commands can be used only when sfdx-project.json is available, as it determines the order of the packages to be installed, so it could only be used in a linear pipeline such as build -> deploy(sit) -> deploy(uat) -> deploy(prod). If a different strategy is used, where multiple commits are accumulated to form builds and builds aggregated before deploying. In this case, we recommend to use the orchestrator till your daily/immediate testing environment, once from there the artifacts are published into a artifact repository, a script based model (using the non orchestrator commands) could be applied for deploying into higher environments.
​