Skip to content

Build

Unlike CentOS SIGs, CentOS Stream has its own buildsystem, its own sources, and its own release pipeline.

What's interesting is that Red Hat's internal setup for building Red Hat Enterprise Linux (RHEL) works basically same way, and the two build systems are in sync (as illustrated below). RHEL maintainers work in CentOS Stream first, and both the sources and builds are mirrored internally. This means that CentOS Stream is truly the place where RHEL gets put together in public.

Building CS and RHEL together

Builds

CentOS Stream has its own dedicated buildsystem, the CentOS Stream Koji. Only RHEL maintainers are allowed to build in this buildsystem.

The majority of packages now use the RHEL On Gitlab (ROG) pipeline, which is a merge-request-based build pipeline. Some packages still use the older pipeline. The pipeline a package uses affects how builds flow through the system and which Koji tags you will see.

ROG pipeline builds use draft builds — a Koji feature that allows multiple builds with the same NVR (Name-Version-Release). This means a package can be built and tested multiple times before a final build is promoted.

Gating

Every build passes through automated gating tests. Right now, these tests are run internally to Red Hat. The specifics depend on which pipeline the package uses.

You can follow any build by observing its tags in Koji.

Older pipeline tags

Packages that are NOT using the ROG workflow follow these tags, in order:

  1. c10s-gate - This is where builds first land immediately after they are built.
  2. c10s-candidate - These packages have passed gating based on RHEL CI testing.
  3. c10s-pending - These packages have passed gating and preverification. These packages are also added to the buildroot when tagged here.
  4. c10s-pending-signed - These packages have been signed by the signing automation, and are ready for compose.
ROG pipeline tags

Packages using the ROG workflow follow these tags, in order:

  1. c10s-draft - This is where builds first land immediately after they are built using the ROG workflow.
  2. c10s-candidate - These packages have passed all ROG tests, and have been promoted by the maintainer.
  3. c10s-pending - These packages have passed preverification. These packages are also added to the buildroot when tagged here.
  4. c10s-pending-signed - These packages have been signed by the signing automation, and are ready for compose.

Packages built through the ROG pipeline using Konflux will also be tagged with c10s-konflux-draft alongside c10s-draft. This additional tag identifies that the build was done by Konflux. The build then proceeds through the normal ROG tags above.

Other tags
  • c10s-build - This is the buildroot. It inherits packages from the c10s-pending tag.
  • c10s-released - The release system automatically applies this to all builds that got released.

Note that the c10s part means CentOS Stream 10, and can also be c9s for CentOS Stream 9 etc.

If you see a package in the -gate tag, you know it was built using the older pipeline. If you see a package in the -draft tag, you know it was built using the ROG pipeline. A package with the -konflux-draft tag was built by Konflux as part of the ROG pipeline.

Examples

Konflux

What is Konflux?

Konflux is a Kubernetes-native build and delivery platform, an open-source project led by Red Hat. It is built on Kubernetes and uses Tekton pipelines to orchestrate builds, tests, and releases.

Konflux is designed with security and reproducibility as core principles:

  • Hermetic builds — builds can run in network-isolated environments using a precomputed set of dependencies, producing deterministic, reproducible results.
  • Artifact signing — built artifacts are signed and include provenance metadata.
  • SBOMs — Software Bills of Materials are generated for every build, providing a complete record of what went into the artifact.

Konflux is being adopted to modernise the RPM build pipeline for both CentOS Stream and RHEL, working alongside the existing Koji buildsystem.

How Konflux fits into CentOS Stream

The ROG pipeline is being extended to use Konflux for building CentOS Stream RPMs. In this model:

  • A merge request on GitLab triggers the ROG CI pipeline.
  • The ROG pipeline submits a PipelineRun to Konflux.
  • Konflux orchestrates a Tekton pipeline that builds the RPM.
  • Built RPMs are imported into the CentOS Stream Koji via CGImport.

Koji remains the source of truth for package state and tagging. Konflux handles the build execution, while Koji continues to manage the lifecycle of the package from draft through to release.

The Konflux build flow

When a build is triggered, Konflux runs a series of Tekton tasks in order:

Step What happens
Clone repository The source repository is cloned at the requested commit and published as an immutable snapshot.
Get RPM sources RPM inputs (spec file, patches, tarballs) are assembled from the repository.
Calculate dependencies The buildroot is computed for each target architecture (e.g. x86_64, aarch64, s390x, ppc64le).
Build RPMs RPMs are built using Mock inside an isolated environment, one build per architecture.
Upload artifacts Built RPMs, logs, and SBOMs are uploaded and made available for downstream steps.

After a successful build, the RPMs land in Koji as draft builds and proceed through the normal tagging flow described above.