Branches

Branches

A branch is a named, isolated slice of a project’s configuration. Every workflow, DUT, storage item, and label belongs to exactly one branch. This mirrors the branches in your version-control repository: the configuration on your main branch can differ from the configuration on a feat/... branch, and jobs triggered from each land against the matching branch.

A project holds branches, and each branch holds its own configuration:

Project
└── Branch (e.g. "main")
    ├── Workflows
    ├── DUTs
    ├── Storage
    └── Labels

Branch Types

A branch has a type that records how it was created.

TypeCreated byTypical use
gitA VCS webhook push or mergeConfiguration tracked in your repository, updated automatically on every push.
archiveManaged by the serverHolds the configuration and jobs of removed branches. Not created or targeted directly.

Every branch you work with is a git branch — it mirrors a branch of your repository. The archive type is internal and never a run target.

The Default Branch

Each project has exactly one default branch. When a trigger does not name a branch, the server resolves the lookup against the default branch. The default is normally the git branch matching your repository’s default branch (e.g. main).

The Archive Branch

Each project has a single, server-managed archive branch of type archive. You never create, push to, or trigger jobs against it directly — it exists so that nothing is silently lost when a branch goes away.

When you delete a branch (for example by deleting the branch on your remote, see Lifecycle), the server does not discard that branch’s data. Instead it moves the branch’s dependents — workflows, DUTs, storage, and the jobs that ran against them — onto the project’s archive branch. This keeps historical results reachable:

  • Job history survives branch deletion. Reports and logs for jobs that ran on a deleted branch remain accessible rather than disappearing with the branch.
  • It is read-only in practice. New jobs are never scheduled against the archive branch; it only accumulates the leftovers of removed branches.
  • One per project. There is at most one archive branch per project, and it is created and maintained automatically.

If you need to revive archived configuration, push it again onto a live git branch — the archive itself is not a working branch.

Lifecycle

  • Creation — A git branch is created automatically the first time a webhook push for that branch reaches the server.
  • Update — Each subsequent push to the same branch updates that branch’s configuration in place.
  • Deletion — Deleting a branch on the remote sends a delete webhook; the server removes the corresponding git branch (best-effort) and moves its dependents to the archive branch so jobs and history stay reachable.

How Branches Are Selected

The branch a job runs against depends on the trigger:

TriggerBranch resolution
VCS webhook (GitHub/GitLab)The pushed branch, as a git branch (full ref name, e.g. feat/new-board).
GitHub Action / GitLab CIThe BRANCH input, defaulting to the detected ref.
fwci job / fwci exec-b/--branch, else the local git branch, else interactive. Falls back to default.
REST POST /v0/jobbranch_name, else the project default branch.

See Also