Architecture Of Konflux

63. Generalized Build and Release Pipelines

Date: 2026-03-17

# Status

Implementable

# Context

Konflux was originally designed to produce container images. As a result, all of Konflux’s core software modeling APIs (Application, Component, Snapshot) assume a container image is used to store and distribute software artifacts. Dependencies between components were assumed to be represented as container image references in source code. Container image standards (OCI) are also used to associate secure software supply chain metadata (signatures, attestations, and SBOMs) with executable code.

Over the past year, the Konflux community has added build and release pipelines for non-container software, such as RPMs and Python wheels. It is clear that Konflux aspires to be a universal secure software factory, and therefore should support additional software ecosystems such as npm (NodeJS) and Maven (Java).

This ADR codifies and generalizes the patterns for building and releasing non-container software.

# Definitions

For the remainder of this ADR, the term “OCI image” will refer to any artifact that meets the OCI image specification. This can refer to runnable images, index images, or non-runnable OCI artifacts.

The terms “artifact” and “package” will use the SLSA v1.2 definition of these terms, namely:

This ADR will also introduce the term “package identity”, with the following definition:

A "package identity" is a reference to a specific package artifact within or belonging to a package
name. This is often known as a "package version" within package ecosystems, however:

- The format and requirements of such identity can vary across package ecosystems. SemVer v2 format
  is often encouraged, but not always required.
- A package artifact may have one or more package identities at a given point in time, subject to
  the requirements of the artifact's package ecosystem.
- Package identities are not required to be immutable, depending on the requirements of its related
  package ecosystem.

“Software” may be used as a preceding adjective for the above terms to distinguish artifacts containing executable code from supplementary metadata artifacts, such as Software Bill of Materials (SBOMs), signatures, and security scan reports.

# Decision

# Consequences

# Alternatives Considered

# Publish Build Artifacts to Native Package Registries

This sub-feature would have required build pipelines to publish artifacts to a native “development” package registry for the component’s package ecosystem. Release pipelines would then be responsible for promoting components from “development” repositories to “release” repositories. In this alternative, the Component Build Artifact is a thin artifact (ex: a single layer with a JSON file) containing references to the artifacts published to the development package registry.

Konflux is currently built on two core principles that are at times in conflict with non-container package development workflows:

# Requirements and Benefits

Publishing build artifacts to native “development” package repositories would require the following:

There are multiple benefits to this approach:

# Drawbacks and Blockers

Potential downsides and blockers for this approach include:

  1. Release pipelines will need to modify build version identifiers during the publication process. Example: A package with build version id 1.3.2.dev20260311-1345 is published as 1.3.2. This may require modifications to built package artifacts depending on the package ecosystem.
  2. The destination package registry must enforce version immutability. It is not clear if this is universally true, or depends on the particular package registry provider. Konflux aspires to be a “neutral” upstream when possible, and moving forward we should design solutions based on agreed standards.
  3. Package ecosystem tooling must be able to document all artifacts that are published to respective package registries, preferably in machine-readable formats. This data would be stored in the Component Build Artifact referenced above. Not all tooling produces this data today (ex: Maven Deploy Plugin).
  4. We have existing precedent in Konflux for using non-container OCI artifacts to publish content through a release pipeline. See ADR-0049.
  5. Component nudging and primary artifact distribution are separate concerns. The blockers above apply specifically to using native registries as the primary storage/distribution mechanism during the build phase. Alternative nudging approaches (tenant release pipelines, MintMaker) are potentially viable for addressing developer workflow needs.

Items 1, 2, and 3 above are considered “high risk”/“blockers” for adopting the “native package registry” approach.

# Workarounds

Developers have the following alternatives at their disposal:

In some respects “nudging” is an implied automatic Konflux Release to a development (container) package registry.

# Reasons to Reconsider

Using native package repositories (in general or on a per-ecosystem basis) may be reconsidered based on the following criteria:

# Document Published Artifacts in Release Object

This sub-feature would have deprecated the current unstructured status.artifacts field and replaced it with the following fields:

Example YAML:

apiVersion: appstudio.redhat.com/v1alpha1
kind: Release
spec:
  ...
status:
  additionalData: # Begin unstructured YAML
    sboms:
      component:
    ...
  packageArtifacts:
    - checksum: "sha256:<checksum-hash>" # format <algorithm>:<checksum>
      ecosystem: oci # Can be other types, such as `maven`, `npm`, `rpm`, etc.
      identities:
        - "@sha256:<digest>"
        - "10.0.2-20260113-15845"
        - "10.0.2"
        - "10.0"
        - "10"
        - "latest"
      name: ubi10/ubi
      platform: # optional - used to describe os/arch specific package artifacts
        os: linux # GOOS values. If not set or empty, the package is OS-agnostic.
        arch: amd64 # GOARCH values. If not set or empty, the package is CPU-agnostic.
      registry: registry.redhat.io

The current status.artifacts field is capable of storing this data, albeit without any OpenAPI schema validations provided by Kubernetes Custom Resource Definitions. This feature is not a hard requirement to generalize builds and releases on Konflux, however it may be reconsidered through a follow-up feature or ADR.

# Publish Conforma Policies Alongside Build Pipelines

This sub-feature would have required build pipeline repositories to include Conforma policies that verified the build pipeline execution. This idea had far reaching consequences for how Conforma policies are defined today:

This idea was considered too large to be included in this ADR. The community is seeking a follow-up ADR from Conforma experts who could refine this idea further.