# Builds

<figure><img src="https://1175714801-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh59zbGOCxlW2afrUhmcZ%2Fuploads%2Fgit-blob-49f8d332a0be4e4b964ca26c7e367c548e2447ef%2Fbuilds-page.png?alt=media" alt="Builds page"><figcaption><p>The Builds page showing completed builds with commit details, packages, and versions</p></figcaption></figure>

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

1. **codev detects the merge** and figures out which [domains](https://docs.flxbl.io/flxbl/codev/overview-1#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](https://docs.flxbl.io/flxbl/codev/ci-cd/overview-1) 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**.

{% hint style="info" %}
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.
{% endhint %}

### 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:

```json
"branches": ["main", "develop"]
```

### 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](https://docs.flxbl.io/flxbl/sfp/development/defining-a-domain/release-config) 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](https://docs.flxbl.io/flxbl/sfp/building-artifacts/controlling-aspects-of-the-build-command/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](https://docs.flxbl.io/flxbl/sfp/building-artifacts/controlling-aspects-of-the-build-command/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](https://docs.flxbl.io/flxbl/sfp/building-artifacts/controlling-aspects-of-the-build-command/selective-ignoring-of-components-from-being-built).
* **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](https://docs.flxbl.io/flxbl/sfp/building-artifacts/controlling-aspects-of-the-build-command/use-of-multiple-config-file-in-build-command).

All package types are supported: source packages, unlocked packages, org-dependent unlocked packages, data packages, and diff packages. See [Supported package types](https://docs.flxbl.io/flxbl/sfp/concepts/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

* [Release Candidates: Review and deploy what was built](https://docs.flxbl.io/flxbl/codev/ci-cd/overview-1)
* [Releases: See what is deployed where](https://docs.flxbl.io/flxbl/codev/ci-cd/overview-2)
* [sfp: Building artifacts](https://docs.flxbl.io/flxbl/sfp/building-artifacts/overview)
* [sfp: Controlling builds](https://docs.flxbl.io/flxbl/sfp/building-artifacts/controlling-aspects-of-the-build-command)