Inside Fedora 45's Build Pipeline: From a Git Push to Installable Images

A packager’s commit to a per-package Git repo on src.fedoraproject.org is the starting point for every Fedora artifact. The fedpkg tool wraps the routine work, and its build command’s real trick is handing Koji a URL pinned to a specific commit hash, making each build reproducible from source. Koji, Fedora’s hub-and-spoke build system since Fedora 7, spins up a clean Mock chroot for every job so results never depend on leftover state, and organizes everything through inheritable tags that separate the buildroot from where finished builds land. Beyond RPMs, Koji also drives image builds — Kiwi, Image Builder, and OSTree composes — through its plugin and content-generator system.

Finished builds don’t reach users automatically. For branched releases, Bodhi gates updates through a testing cycle driven by user and automated karma, with stricter rules (14 days, more karma) for critical-path packages that the system needs to boot. Under the hood, Bodhi simply moves builds between Koji tags and triggers a compose of the repository that dnf pulls from, while integrating with Greenwave and ResultsDB so failed CI can block a release. Rawhide runs a looser variant of the same machinery.

Turning gated packages into ISOs, cloud images, and repos is Pungi’s job. It orchestrates rather than does the heavy lifting: it first freezes a package set snapshot from a Koji tag so nothing sneaks in mid-compose and every release stays auditable, then uses comps and variants XML to decide which packages land in which product. Most modern variants are empty, producing only images from the Everything repository. The Buildinstall phase runs lorax to create boot.iso for the Anaconda installer, which later phases overlay with packages to build full DVD ISOs. The author notes the doc is still living — Fedora 45 isn’t released yet, and in-flight change proposals may still alter how boot.iso is produced.