Different types of validation
sfp has a comprehensive collection of validation techniques one can adopt according to requirements of your projects. Read on more about various validation modes to achieve your objective
Validate Modes
Individual
Ignore packages installed in scratch org, identify list of changed packages from PR/Merge Request, and validate each of the changed packages (respecting any dependencies) using thorough mode.
--mode=individual
Fast Feedback
Skip package dependencies and code coverage and selective test class executions, install only changed components, and ignore changes in package descriptors
--mode=fastfeedback
Thorough (Default)
Include package dependencies, code coverage, all test classes during full package deployments
--mode=thorough
Fast Feedback Release Config
Extension of fast feedback mode but filtered using release configuration file that defines list of packages to validate with only changed packages ending up being used to validate against the scratch org
--mode=ff-release-config
--releaseconfig=<value>
Thorough Release Config
Extension of thorough default mode but filtered using release configuration file that defines list of packages to validate with only changed packages ending up being used to validate against the scratch org
--mode=thorough-release-config
--releaseconfig=<value>
Sequence of Activities
The following are the list of steps that are orchestrated by the validate command If used with pools
Fetch a scratch org from the provided pools in a sequential manner or
Authenticate to the Scratch org using the auth URL fetched from the Scratch Org Info Object
If used against a provided org
Authenticate to to the provided target org
Build packages that are changed by comparing the tags in your repo against the packages installed in the target
For each of the packages (internally calls the Install Command) Thorough Mode (Default)
Deploy all the built packages as source packages / data packages (unlocked packages are installed as source package)
Trigger Apex Tests if there are any apex test in the package
Validate test coverage of the package depending on the type of the package (source packages: each class needs to have 75% or more, unlocked packages: packages as whole need to have 75% or more)
Fast Feedback Mode
Deploy only changed metadata components for built packages as source packages / data packages
Trigger selective Apex Tests based on impact analysis of the changes in the package
Skip coverage calculations
Skip deployment of package if the descriptor is changed
Skip deployment of top level packages direct dependency on the package containing changed components
Individual Mode
Ignore packages that are installed in the scratch org (basically eliminate the requirement of using a pooled org)
Compute changed packages by observing the diff of Pull/Merge Request
Validate each of the changed packages (install any dependencies) using Thorough Mode
Fast Feedback Release Config Mode
Inherit Fast Feedback Mode Features but filtered using a release configuration file containing list of packages to focus validation on
Deploy only change packages in the list by comparing against what is installed in the org
Thorough Release Config Mode
Inherit Thorough Mode Features but filtered using a release configuration file containing list of packages to focus validation on
Deploy only change packages in the list by comparing against what is installed in the org
Use of default "thorough" mode is still recommended in the pipeline with fast feedback to ensure coverage computation and scripts added to the descriptor files are correctly working and deployable in an empty org.
By default, all the apex tests are triggered in parallel, with an automated retry, where any tests that fail to execute due to SOQL locks etc are retried synchronously. You can override this behaviour using --disableparalleltesting which will trigger tests every time in synchronous mode.
Last updated