dist-git
The release pipeline picks up readyForMerge source-git MRs and produces
a dist-git MR. This MR triggers an official build and tier 1 smoke testing
before it can be merged.
Build
The dist-git MR triggers an official kernel build in Brew. If the build fails, the kernel maintainer investigates and fixes the issue, restarting the cycle.
Smoke testing (kt1)
Once the build succeeds, kernel tier 1 (kt1) smoke tests run against the
official RPM build. Depending on the dist-git workflow variant, testing is
triggered via the kernel-draft or kernel-gate schedule in
qe-pipeline-definition (identical tests, different reporting). These tests
cover areas important enough to block kernel delivery to customers: boot and
basic functionality, real-time guarantees, RPM signing, and kernel module ABI
stability. Test definitions live in kernel-tests (tagged with
KernelTier1).
Test failures are evaluated with Known Issue Detection (KID) to filter out known pre-existing issues (see Future workflow for planned changes).
Maintainer investigation
When smoke testing finds an unknown failure, the kernel maintainer investigates. Anything that fails here is by definition important enough to block — the point of kt1 is to catch issues that should prevent delivery.
- Real issue: the failure is escalated and fixed in the appropriate place (src-git, infrastructure, test code, etc.), restarting the build cycle.
- Infrastructure / test flake: QE files a JIRA issue and a new known issue in DataWarehouse, which automatically waives the test failure so the MR can proceed. These are not product issues but still need tracking.
Merge
Once the build succeeds and smoke testing passes (or failures are waived), the dist-git MR is merged. This produces the official build that proceeds to the release phase.
Future workflow
The dist-git workflow is evolving with similar changes to src-git:
Build system: The build moves from Brew to Konflux.
Test pipelines: Smoke testing pipelines move from qe-pipeline-definition with known issue detection to RHEL-on-GitLab OSCI tier0 testing based on Testing Farm without known-issue detection.
Waiver process: Ideally, no test results are waived. If still necessary, the maintainer waives unrelated failures via the standard OSCI waiver mechanism.