Builds
codev comes with a built-in CI/CD system. When someone merges code into your repository, codev automatically builds the affected Salesforce packages and prepares them for deployment. No external CI/CD tool or pipeline configuration is needed — it works out of the box.
Think of this as the step where your metadata changes are packaged up and made ready to deploy. codev does it automatically on every merge, and it only builds what actually changed.
What happens when code is merged
codev detects the merge and figures out which domains were affected by the change. Packages in unaffected domains are skipped entirely.
Each affected package is built — codev compiles the metadata, runs any configured validations, and produces a versioned artifact. An artifact is a snapshot of your package at that point in time, tagged with a version number.
A release candidate is created — once all affected packages are built, codev bundles them into a release candidate. This is the thing you will later deploy to your sandboxes or production org. It appears automatically on the Release Candidates page.
Builds within the same repository and branch are queued — if two developers merge back-to-back, the second build waits for the first to finish. This prevents conflicts during artifact publishing.
Configuring builds
Enabling and disabling
The Build on Merge workflow is enabled by default. To turn it off, click Workflow Settings on the Builds page and toggle Build on merge.
If you also run builds from your own CI/CD pipelines (using sfp build + sfp publish), those builds always appear on this page regardless of the Build on Merge setting. codev's built-in workflow and external pipelines coexist.
Building on other branches
By default, codev only triggers builds for merges to main. To build on additional branches (e.g., develop, release/*), go to Settings > Organization > Projects, click your project, and add the branches to the branches array:
Excluding specific branches
If Build on Merge is enabled but you want to skip certain branches, click Workflow Settings and use Exclude specific branches. This supports wildcard patterns like release/* or hotfix-*.
Controlling what gets built
codev uses release configs in your repository to determine which packages belong to which domain. Beyond that, you can control the build process through your project's sfdx-project.json:
Skip a package from builds entirely — add
"ignoreOnStage": ["build"]to the package entry insfdx-project.json. The package will be ignored during all builds. See Ignoring packages from being built.Build packages together as a group — use the
"buildCollection"attribute to ensure a set of packages always builds together when any one of them changes. See Building a collection of packages together.Ignore specific metadata components — use per-stage
.forceignorefiles to exclude certain components from the build. See Selective ignoring of components.Use different scratch org definitions per package — configure
scratchOrgDefFilePathsinsfdx-project.jsonif different packages need different org shapes for validation. See Multiple config files.
All package types are supported: source packages, unlocked packages, org-dependent unlocked packages, data packages, and diff packages. See Supported package types.
Artifact details
Clicking the artifact action on any build row opens a side panel showing the full picture of what was built — package type, metadata counts, whether Apex was found, test coverage results, and publishing timestamps.
From builds to release candidates
Builds that successfully publish artifacts and generate a release definition produce a release candidate. The RC name appears below the package name in the builds table.
If a build shows Completed but no RC name appears, the release definition generation may have failed. Click the sfp Server link in the build row to inspect the workflow execution logs.
Related
Last updated