OfBorg and CI¶

Overview¶

OfBorg is the Nixpkgs pull-request CI bot. It evaluates changed Nix expressions and selectively builds affected packages on shared builders, reporting status on GitHub. OfBorg runs before merge on PRs; Hydra evaluates and builds after merge on trunk branches and drives official channels. The two systems overlap in purpose (catching breakage) but operate at different stages of the contribution flow.

Details¶

What OfBorg does on PRs¶

Per CONTRIBUTING.md, OfBorg performs checks to ensure code quality; results appear at the bottom of the PR.

Typical OfBorg work on a pull request:

Evaluation — instantiates Nixpkgs and NixOS release expressions (nix-instantiate on ./pkgs/top-level/release.nix and ./nixos/release.nix, -A manual). Every PR is evaluated automatically when opened and when commits change; re-running @ofborg eval is rarely needed unless eval failed oddly or master was previously broken.
Selective builds — when commit titles follow Nixpkgs conventions (package attribute as prefix, e.g. vim: 1.0.0 -> 2.0.0), OfBorg schedules builds for the detected attributes. Multiple commits pushed one-by-one each get a separate build job; a multi-commit PR opened at once gets one job for all detected packages. WIP-titled PRs (WIP: prefix or [WIP] anywhere) skip automatic builds; draft status alone does not.
NixOS tests — @ofborg test … runs selected nixosTests.* attributes when requested.

Builders use sandboxed nix-build / nix-instantiate with restrict-eval, a 1800s build timeout, and per-system --argstr system (see the OfBorg README for the exact command shapes).

PR comments and commands¶

Reviewers and contributors can trigger extra work by commenting on the PR. Lines must start with @ofborg (case insensitive). Supported subcommands from the OfBorg README — Commands:

Command	Effect
`@ofborg build attr1 attr2 …`	`nix-build ./default.nix -A …` for each attr
`@ofborg test name1 name2 …`	builds `nixosTests.name1`, …
`@ofborg eval`	re-runs release-expression instantiation

Multiple @ofborg lines (or several commands on one line) are allowed; commentary may be interwoven as long as bot lines start with @ofborg. Do not append free text on the same line after build/test attrs—those words become attribute names.

Guidelines from upstream: review code before triggering the bot; avoid mass rebuilds or very large builds (e.g. Chromium) on shared infrastructure.

Trusted users (operational note): the README’s trusted-user gate (extra platforms for a short allowlist) is currently disabled; all users’ builds/tests may run on available platforms including Darwin. Confirm current state in the OfBorg README / config.public.json before relying on platform differences.

Required checks vs OfBorg status¶

GitHub required status checks (jobs named like PR / …) can block merge when they fail. As stated in CONTRIBUTING.md, OfBorg is not required by those checks—merge gating and OfBorg reports are separate concerns. A PR may still need human review and green required checks even when OfBorg is pending or ignored.

OfBorg builds can stall (notably on PRs targeting staging or on Darwin builders). Reviewers often know when to wait or disregard stuck jobs; contributors should still fix failures caused by their change. Platform gaps surfaced by OfBorg may warrant meta.broken, meta.badPlatforms, or meta.platforms adjustments—see package sets for how platform support tiers steer CI coverage.

Local review alongside OfBorg¶

OfBorg covers a subset of platforms and attributes per PR. Contributors often run nixpkgs-review locally to rebuild dependents of a change (nixpkgs-review pr <number> or wip on uncommitted work)—see CONTRIBUTING’s PR template section. Local sandboxed builds mirror Hydra’s environment; see builders and sandboxes and binary caches when reproducing CI locally.

Maintainers, merge-bot, and notifications¶

Listed meta.maintainers receive notifications on relevant PRs. That is distinct from OfBorg itself. The nixpkgs-merge-bot is a separate automation for eligible pkgs/by-name merges by maintainers—see Maintainers and teams.

After merge: Hydra and channels¶

Once a PR lands on master, nixos-unstable, or release branches, Hydra jobsets take over: regular evaluation and builds, then channel updates when jobsets succeed. That pipeline must not be treated as a substitute for pre-merge testing—CONTRIBUTING warns against using Hydra as a testing platform.

Stage	System	Scope
Pull request	OfBorg	Changed attrs, eval, optional tests; comment-triggered builds
Trunk / release branches	Hydra	Full jobsets, channel promotion
Local	`nixpkgs-review`, `nix-build`	Contributor-chosen depth

Branch-specific Hydra usage (e.g. staging vs staging-next) is covered in Staging and branches. Channel lag and promotion are summarized in Channel.

Examples¶

Request OfBorg builds for specific attributes (PR comment; syntax from the OfBorg README):

@ofborg build hello vim

Run selected NixOS tests:

@ofborg test nginx

Minimal local check of a PR’s rebuild closure (after installing nixpkgs-review):

nix run nixpkgs#nixpkgs-review -- pr 12345