October 23
Ask or search…
Comment on page

Build & Quick Build

Build your packages in parallel
Build and its variant quickbuild are commands builds packages in your build stage of the pipeline. These commands provide the following benefits
  • Reduce time taken to build unlocked packages, by triggering the package creation commands in parallel provided dependencies are built
  • Reduce efforts in reducing maintenance of builds scripts, when you have multiple packages.
During quickbuild, unlocked packages are built without triggering dependency validation or code coverage check. however build commands generate fully validated packages that can be deployed to production (after promotion). Packages generated by quickbuild cannot be deployed to production.
We recommend using quickbuild, to generate packages upon every merge and then deploying the package to your test org's. When you have tested successfully, you could use the build command to generate validated packages
Both Build & Quickbuild are equipped with a diffcheck functionality, which is enabled when one utilizes diffcheck flag, A comparison (using git diff) is made between the latest source code and the previous version of the package, defined by a tag that follows semantic versioning. If any difference is detected in the package directory, package version or scratch org definition file (applies to unlocked packages only), then the package will be created - otherwise, it is skipped.
Please note the build command should not be run concurrently. Ensure you design your pipeline in such a way that only one build stage is run at any given point in time. Running parallel build commands could result in package with incorrect dependencies.

Determining Package to be built

These commands follow the order of the the packages as ordered in your sfdx-project.json. The commands also read your dependencies property, and then when triggered, will wait till all its dependencies are resolved, before triggering the package creation command. For eg: provided the followings packages
Scenario 1 : Build All
  1. 1.
    Trigger creation of package A
  2. 2.
    Once A is completed, trigger creation of package B & C **,**using the version of A, created in step 1
  3. 3.
    Once C is completed, trigger creation of package
Scenario 2 : Build with diffCheck enabled on a package with no dependencies
In this scenario, where only a single package has changed and diffCheck is enabled, the build command will only trigger the creation of Package B
Scenario 3 : Build with diffCheck enabled on changes in multiple packages
In this scenario, where there are changes in multiple packages, say B & C, the build command will trigger these packages in parallel, as their dependent package A has not changed (hence fulfilled). Please note even though there is a change in C, package D will not be triggered, unless there is an explicit version change of version number (major.minor.patch) of package D

Versioning Packages

Utilize the .NEXT and .LATEST for versioning the build number of unlocked packages. For Source and Data package, utilize the "buildnumber" flag and provide the build number from your CI/CD system

Ignoring Packages from being built

Using the ignoreOnStage:[ "build" ] property on a package, causes the particular package to be skipped by the build command. Similarly you can use ignoreOnStage:[ "quickbuild" ] to skip packages in the quickbuild stage.

Distinct Scratch Org Definition

This feature allows a user to specify a unique scratch org config file for a package. When the feature is enabled and the package name is matched, the build command will use specified config file for that package.
"plugins": {
"enableMultiDefinitionFiles": true,
"packages": {