Read on newly released AI assisted Insights
flxbl docs
Ctrlk
Learn CD Concepts using LabsslackGitHub
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Builds

Builds page
The Builds page showing completed builds with commit details, packages, and versions

codev comes with a built-in CI/CD system. Once server builds are enabled (see Enabling and disabling — they are off by default), a merge into your repository builds the affected Salesforce packages and prepares them for deployment. No external CI/CD tool or pipeline configuration is needed.

This is the step where your metadata changes are packaged up and made ready to deploy. codev runs it on merge once enabled, and it only builds what actually changed.

What happens when code is merged

  1. codev detects the merge and figures out which domains were affected by the change. Packages in unaffected domains are skipped entirely.

  2. 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.

  3. 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

Server-managed builds are off by default. To turn them on, click Workflow Settings on the Builds page and toggle Enable server builds. Until this is on, a merge does not trigger a build and the build is recorded as Skipped.

Build Workflow Settings dialog with the Enable server builds toggle off
Build Workflow Settings, reached from Workflow Settings on the Builds page. Enable server builds is off by default — turn it on for merges to trigger builds.

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 Enable server builds 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

With server builds enabled but you want to skip certain branches, click Workflow Settings and use Exclude specific branches. This supports wildcard patterns like release/* or hotfix-*.

Deploying to environments by branch

codev selects which environments a build deploys to by their Branch association: each environment tracks a branch, and a build deploys to the environments that track the branch it ran on.

The Branch field accepts an exact name or a glob pattern, so one environment can serve a class of branches without being reconfigured for each new branch:

  • release/* — every release branch

  • release-patch-* — every patch branch cut from a release candidate

An exact name such as develop matches only that branch. Set the field when creating or editing an environment: pick an existing branch from the list, or type a pattern. Production environments are not deployed to on merge — they receive releases through release candidates.

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 in sfdx-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 .forceignore files to exclude certain components from the build. See Selective ignoring of components.

  • Use different scratch org definitions per package — configure scratchOrgDefFilePaths in sfdx-project.json if 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

Was this helpful?