# Konflux Resource Deployment

> How Konflux resources are defined and deployed across repositories

---

LLMS index: [llms.txt](https://hummingbird-project.io/llms.txt) | Full content: [llms-full.txt](https://hummingbird-project.io/llms-full.txt)

---

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

[containers]: https://gitlab.com/redhat/hummingbird/containers
[infrastructure]: https://gitlab.com/redhat/hummingbird/infrastructure

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](https://hummingbird-project.io/docs/background/containers/image-pipeline/). Keeping policy and documentation together eases
   maintenance.

### Infrastructure Repo

**Application, ReleasePlan, and IntegrationTestScenario** are defined in
`kubernetes/containers-*/` directories (one per Konflux application):

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*/` directories (one per Quay organization):

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
each `quay.io/hummingbird*` organization.

## See Also

- [Image Pipeline](https://hummingbird-project.io/docs/background/containers/image-pipeline/) – Build, test, and release stages