Konflux Resource Deployment

How Konflux resources are defined and deployed across repositories

Konflux resources for container images are split between two repositories:

  • containers: Per-image resources generated from properties.yml
  • infrastructure: Application-level resources and deployment to the Konflux cluster

This separation allows independent iteration on each concern.

Deployment Matrix

Resource Type Source Containers MR Containers Push Infra MR Infra Push
Component containers manual manual - -
ImageRepository containers manual manual - -
ReleasePlanAdmission containers - automatic manual automatic
EnterpriseContractPolicy containers - automatic manual automatic
Application infrastructure - - manual automatic
ReleasePlan infrastructure - - manual automatic
IntegrationTestScenario infrastructure - - manual automatic
ServiceAccount, Secret infrastructure - - manual automatic

Legend:

  • Containers MR: Downstream pipeline triggered from containers MR (deploys from MR commit)
  • Containers Push: Downstream pipeline triggered from containers push to main
  • Infra MR: Infrastructure MR pipeline (manual trigger)
  • Infra Push: Infrastructure push to main or web pipeline

Resource Locations and Rationale

Containers Repo

Resources are defined in konflux-templates/ and rendered to konflux-templates/rendered.yml.

Component and ImageRepository:

  1. Ownership: Components are managed by the containers repo. The infrastructure pipeline uses ONLY_DOWNSTREAM so only explicit downstream triggers from containers deploy changes, giving the containers repo full control over the component lifecycle.
  2. Dynamic generation: Generated from images/*/properties.yml via ci/internal/generate_konflux_resources.sh, depending on per-image configuration (variants, tags, repository names).
  3. Timing: Must be deployed early during MR review so Konflux can build and test new images.

ReleasePlanAdmission:

  1. Dynamic generation: Includes per-image tag mappings extracted from properties.yml.
  2. Main branch only: Prevents race conditions—deploying from a feature branch risks undoing other images’ onboarding. If branch A adds image-foo and branch B (created earlier) adds image-bar, deploying B’s RPA would remove image-foo from the release config.

EnterpriseContractPolicy:

  1. Documentation co-location: Policy exclusions are documented in Image Pipeline. Keeping policy and documentation together eases maintenance.

Infrastructure Repo

Application, ReleasePlan, and IntegrationTestScenario are defined in kubernetes/containers-main/ and kubernetes/containers-ci-main/:

  1. Independent iteration: Changes are decoupled from containers repo activity—they can be modified, test-deployed via manual trigger in an infrastructure MR, verified, and merged without touching the containers repo.
  2. Testable before merge: If defined in the containers repo, these would only deploy after merging to main (like RPAs), making iteration difficult.
  3. Static configuration: These resources don’t depend on per-image data from properties.yml.

ServiceAccount and Secret for releases are defined in kubernetes/release-quay-hummingbird/ and kubernetes/release-quay-hummingbird-ci/:

  1. Security: Secret specifications (names, structure, credential references) should not be exposed in the containers repo.
  2. Independent iteration: Like other infrastructure resources, these can be modified and test-deployed without touching the containers repo.

The service accounts are referenced by ReleasePlanAdmissions to authorize pushing images to quay.io/hummingbird/ and quay.io/hummingbird-ci/.

See Also