Limiting Validation by Domain

Validation processes often need to synchronize the provided organization by installing packages that differ from those already installed. This task can become particularly time-consuming for large projects with hundreds of packages, especially in monorepo setups with multiple independent domains.

Using Release Configurations

To streamline the validation process and focus it on specific domains, you can use release configurations with the --releaseconfig flag. This approach limits the scope of validation to only the packages defined in your release configuration, significantly enhancing efficiency and reducing validation time.

Basic Usage

sfp validate org -o ci \
                 -v devhub \
                 --mode thorough \
                 --releaseconfig=config/release-domain-sales.yml

In this example, validation is limited to packages defined in the release-domain-sales.yml configuration file. Only packages that:

1. Are listed in the release configuration AND
2. Have changes compared to what's installed in the org

will be validated.

Multiple Domain Configurations

For projects with multiple independent domains, you can specify multiple release configurations:

sfp validate org -o ci \
                 -v devhub \
                 --mode thorough \
                 --releaseconfig config/release-sales.yml \
                 --releaseconfig config/release-service.yml

Benefits of Domain-Limited Validation

1. Faster Feedback: Validate only the relevant packages for your team's domain
2. Reduced Dependencies: Avoid failures from unrelated packages in other domains
3. Parallel Development: Multiple teams can work independently without blocking each other
4. Optimized CI/CD: Shorter validation times mean more efficient pipeline execution

Example Release Configuration

# config/release-sales.yml
releaseName: sales
includeOnlyArtifacts:
  - sales-core
  - sales-ui
  - sales-integrations
  - opportunity-management
  - quote-management

releaseName is the domain name and includeOnlyArtifacts lists the packages in it. Use excludeArtifacts instead to list what to leave out — the two cannot be combined, and a config that sets both is rejected when it loads.

See Release Config for every attribute a release config accepts, including cross-domain dependencies and the properties carried into generated release definitions, and Defining a domain for how domains are structured.

Combining with Other Options

With Diff Check

sfp validate org -o ci \
                 -v devhub \
                 --diffcheck \
                 --releaseconfig=config/release.yml

With Individual Mode

sfp validate org -o ci \
                 -v devhub \
                 --mode individual \
                 --releaseconfig=config/release.yml

With Branch References

sfp validate org -o ci \
                 -v devhub \
                 --ref feature-branch \
                 --baseRef main \
                 --releaseconfig=config/release.yml

Best Practices

Give each domain its own release config. One config per logical domain keeps validation scoped to the team that owns it. Start from Release Config, which documents every attribute, and Defining a domain, which covers how a domain is laid out in the repository.

Declare cross-domain dependencies rather than duplicating packages. Where a domain needs packages another domain owns, list the other domain under dependencyOnDomains. It resolves recursively, so you name the domain rather than tracking its package list as it changes. Copying package names between configs is what falls out of date.

Keep the package list current. A release config that has drifted from the repository silently narrows or widens what a pull request validates. sfp releaseconfig probe -c config/ reads every release config in a directory, which is a quick way to check the set still loads and resolves.

Pass the config explicitly in CI. --releaseconfig is required, so each pipeline states the domain it validates. Where one pipeline covers several domains, pass the flag more than once rather than maintaining a combined config.