6 hours ago
- This document walks through how Fedora turns source code into downloadable artifacts like ISOs, cloud images, container images, and OSTree deployments, using Fedora 45 as the example.
- The process starts with a packager pushing a commit to a package in dist-git (Git repositories at src.fedoraproject.org), where source definitions and downstream patches are stored, while large binaries are kept in a separate lookaside cache.
- Koji, the build system, pulls the Git URL, creates a clean Mock chroot environment for each build, and manages builds through tags, which define build roots and destination tags for packages.
- After building, for branched releases, Bodhi gates updates through a feedback cycle with states like pending, testing, and stable, requiring karma points or testing days before pushing stable updates.
- Pungi composes releases by freezing a package set from a Koji tag, using comps (package groups) and variants XML to define products, then building boot images via Lorax, producing ISOs with xorriso, and creating images with Kiwi and Image Builder.
- Kiwi builds cloud images, Vagrant boxes, container base images, and live ISOs using XML definitions, while Image Builder handles ostree-based and bootc-based artifacts like Atomic Desktop ISOs, Fedora IoT, and Minimal.
- Atomic Desktops like Silverblue use rpm-ostree to compose tree files that produce versioned, checksummed OSTree commits, incorporating packages from comps and treefile specifications.
- Metadata from composes (e.g., composeinfo.json, images.json, rpms.json) is standardized by productmd and used by downstream tools like Anaconda, Bodhi, openQA, and mirror management.
- openQA tests composes automatically by booting images in VMs, running installation and desktop scenarios, and feeding results into release validation.
- Major changes go through a governance process with system-wide or self-contained proposals, reviewed by FESCo, with checkpoints tied to release schedules.