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.
Both Build & Quickbuild is equipped with a diffcheck functionality, which os 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.
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
where B and C is dependent on A, D is dependent on C. The build commands creates packages in the following order
Trigger creation of package A
Once A is completed, trigger creation of package B & C (using the version of A, created in step 1)
Once C is completed, trigger creation of package D
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
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
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.