> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/ci-cd/overview.md).

# Builds

<figure><img src="/files/7dKnhN1UTEUjMbjNhZLn" 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. Once server builds are enabled (see [Enabling and disabling](#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](/flxbl/codev/ci-cd/overview-2.md#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](/flxbl/codev/ci-cd/overview-2.md) 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**.

<figure><img src="/files/fNc6OxBnEl7eO2K31wRo" alt="Build Workflow Settings dialog with the Enable server builds toggle off"><figcaption><p>Build Workflow Settings, reached from <strong>Workflow Settings</strong> on the Builds page. <strong>Enable server builds</strong> is off by default — turn it on for merges to trigger builds.</p></figcaption></figure>

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

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](/flxbl/codev/ci-cd/overview-2.md).

## 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](/flxbl/codev/ci-cd/overview-2.md)
* [Releases: See what is deployed where](/flxbl/codev/ci-cd/overview-3.md)
* [Changesets: Move low-risk metadata without a build (Beta)](/flxbl/codev/ci-cd/overview-1.md)
* [Work items: how they are detected](/flxbl/codev/ci-cd/work-items.md)
* [Cascades: Keep release branches in sync automatically](/flxbl/codev/branch-operations/cascades.md)
* [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)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flxbl.io/flxbl/codev/ci-cd/overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.