Onboard tekton-kueue to kargo-infra-deployments project

[gbenhaim]

What

• Add Kargo warehouse, promotion task, and ring-0 stage for tekton-kueue in the kargo-infra-deployments project
• Warehouse watches quay.io/openshift-pipeline/pipelines-scheduler-rhel9 for new SHA-tagged builds (^[0-9a-f]{40}$)
• Promotion task updates images.0.newTag and resources.0 (git ref) in components/kueue/rings/ring-0/tekton-kueue/kustomization.yaml (infra-deployments repo)
• Ring-0 stage follows the same pattern as konflux-operator (dedicated stage, auto-merge after CI)

Environments affected: internal-production (Kargo project config)

Why

Enable automated promotion of tekton-kueue image updates through the Kargo pipeline, matching the existing pattern used by konflux-operator.

Validation

• kustomize build components/kargo/internal-production/projects/kargo-infra-deployments/ passes ✅

Risk Assessment

Risk Level: Low
What could go wrong: Misconfigured warehouse or promotion task could fail to promote or promote incorrectly. Since this is a new component addition (additive only), no existing pipelines are affected.
Rollback: Revert PR

Made with Cursor

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gbenhaim

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• components/kargo/OWNERS [gbenhaim]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[qodo-for-redhat-appstudio]

PR Summary by Qodo

Onboard tekton-kueue ring-0 promotions in kargo-infra-deployments

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Add tekton-kueue Kargo warehouse, promotion task, and ring-0 stage.
• Watch Quay image tags and open infra-deployments PRs updating kustomize references.
• Auto-merge ring-0 promotions after CI, mirroring konflux-operator automation.

Diagram

graph TD
  Q["Quay image repo"] --> W["Warehouse: tekton-kueue"] --> S["Stage: ring-0"] --> T["PromotionTask"] --> R["infra-deployments repo"] --> PR["GitHub PR"] --> M["Squash merge"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Add explicit required CI checks for tekton-kueue ring-0

• ➕ Prevents auto-merge when only a minimal/default check set runs
• ➕ Aligns safety guarantees with konflux-operator’s wait-for-ci gating
• ➖ Requires knowing/maintaining the correct Prow check regex; may create false negatives if checks are renamed

2. Replace yaml-update with a purpose-built kustomize/image setter step

• ➕ Less brittle than positional YAML keys like images.0/resources.0
• ➕ Can better validate that the target fields exist before committing
• ➖ May require additional tooling/steps not currently standardized in this repo
• ➖ Would diverge from the established konflux-operator pattern

3. Centralize ring-0 Stage template and reuse per-component overrides

• ➕ Reduces duplication across components as more ring-0 stages are added
• ➕ Makes future automation improvements (e.g., PR description tweaks) one-touch
• ➖ Introduces abstraction/indirection in Kargo config which can hinder ad-hoc debugging
• ➖ May not be worth it until more components follow this pattern

Recommendation: The current approach is consistent with the existing konflux-operator ring-0 flow (clone → patch YAML → commit/push → PR → wait-for-ci → merge), which is good for operational consistency. The main follow-up worth considering is adding explicit required CI checks in the wait-for-ci step (as konflux-operator does) to ensure the auto-merge gate is as strict as intended.

Files changed (6) +158 / -0

Other (6) +158 / -0

kustomization.yamlRegister tekton-kueue project overlay +1/-0

Register tekton-kueue project overlay

• Adds the new tekton-kueue Kustomize overlay directory to the kargo-infra-deployments internal-production project so its Kargo resources are applied.

components/kargo/internal-production/projects/kargo-infra-deployments/kustomization.yaml

kustomization.yamlAdd tekton-kueue Kargo resources bundle +7/-0

Add tekton-kueue Kargo resources bundle

• Introduces a Kustomization that wires together the tekton-kueue Warehouse, PromotionTasks, and ring-0 Stage resources.

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/kustomization.yaml

kustomization.yamlWire tekton-kueue promotion task manifest +5/-0

Wire tekton-kueue promotion task manifest

• Adds a Kustomize entry for the ring-0 tekton-kueue PromotionTask definition.

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/promotiontasks/kustomization.yaml

tekton-kueue-promote-ring-0.yamlPromotionTask: update infra-deployments tekton-kueue kustomization +19/-0

PromotionTask: update infra-deployments tekton-kueue kustomization

• Defines a PromotionTask that updates the target infra-deployments kustomization by setting the image tag (images.0.newTag) and the git resource ref (resources.0) based on the discovered image tag.

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/promotiontasks/tekton-kueue-promote-ring-0.yaml

stage-ring-0-tekton-kueue.yamlStage: ring-0 automated promotion + PR auto-merge +112/-0

Stage: ring-0 automated promotion + PR auto-merge

• Adds a ring-0 Stage that clones infra-deployments, runs the tekton-kueue PromotionTask, force-pushes a component branch, opens a PR, waits for CI, then squash-merges the PR automatically.

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/stage-ring-0-tekton-kueue.yaml

warehouse.yamlWarehouse: track tekton-kueue image builds from Quay +14/-0

Warehouse: track tekton-kueue image builds from Quay

• Adds a Warehouse that periodically discovers new image tags from the configured Quay repo and creates freight automatically. Current config uses allowTags: nightly with NewestBuild selection.

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/warehouse.yaml

[qodo-for-redhat-appstudio]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (3) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 5 rules

1. Warehouse image/tag mismatch ✓ Resolved 🐞 Bug ≡ Correctness

Description

The tekton-kueue Warehouse subscribes to quay.io/openshift-pipeline/pipelines-scheduler-rhel10 and
only allows the nightly tag, but the PromotionTask reads the tag from
.../pipelines-scheduler-rhel9. This mismatch means the freight produced by the Warehouse likely
won't contain the image referenced by imageFrom(...), causing promotions to fail (or to promote an
unintended tag/ref if aligned incorrectly).

Code

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/warehouse.yaml[R10-14]

+    - image:
+        repoURL: quay.io/openshift-pipeline/pipelines-scheduler-rhel10
+        imageSelectionStrategy: NewestBuild
+        discoveryLimit: 5
+        allowTags: nightly

Relevance

⭐⭐ Medium

Some evidence team fixes Warehouse tag selection (allowTags tightened in PR #448), but no direct
precedent for repoURL mismatch.

PR-#448

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Warehouse produces freight from a different repository/tag policy than the PromotionTask reads
from, and the repo’s established pattern for SHA-tagged promotions uses a SHA regex allowTags.

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/warehouse.yaml[9-14]
components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/promotiontasks/tekton-kueue-promote-ring-0.yaml[14-19]
components/kargo/internal-production/projects/kargo-infra-deployments/konflux-operator/warehouse.yaml[9-14]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The tekton-kueue Warehouse is producing freight from a different image repository/tag policy than the PromotionTask consumes. This breaks `imageFrom(...)` lookups and prevents correct promotion.

### Issue Context
- Warehouse subscribes to `pipelines-scheduler-rhel10` and `allowTags: nightly`.
- PromotionTask reads Tag from `pipelines-scheduler-rhel9` and uses that tag as both `images.0.newTag` and as a git `ref` for `resources.0`.
- Other component Warehouses in this project use `allowTags: ^[0-9a-f]{40}$` to match SHA-like tags.

### Fix Focus Areas
- components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/warehouse.yaml[9-14]
- components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/promotiontasks/tekton-kueue-promote-ring-0.yaml[14-19]
- components/kargo/internal-production/projects/kargo-infra-deployments/konflux-operator/warehouse.yaml[9-14]

### What to change
1. Make the Warehouse `repoURL` match the repository used by the PromotionTask (or vice-versa), so `imageFrom(<repo>).Tag` resolves from the freight.
2. Update `allowTags` to match the intended tag format for promotion (likely `^[0-9a-f]{40}$` to match the SHA tag pattern used elsewhere), unless `nightly` is intentionally used—in which case adjust the PromotionTask to use the same repo and ensure the resulting `ref` is valid.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Overbroad CI gating defaults ✗ Dismissed 🐞 Bug ☼ Reliability

Description

ring-0-tekton-kueue invokes wait-for-ci without requiredProwChecks, so the PromotionTask default
of .* applies and it requires every non-tide Prow status context on the commit to be success.
This can stall or change Ring-0 auto-merge behavior compared to other Ring-0 stages that restrict
requiredProwChecks to a specific anchored context.

Code

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/stage-ring-0-tekton-kueue.yaml[R79-85]

+        - task:
+            name: wait-for-ci
+          as: wait-for-ci
+          vars:
+            - name: commitSHA
+              value: ${{ outputs['push'].commit }}
+        - uses: http

Relevance

⭐⭐⭐ High

Team accepted tightening requiredProwChecks patterns to avoid overbroad gating behavior in ring
stages (PR #607).

PR-#607

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Stage omits requiredProwChecks, while the shared wait-for-ci task defaults it to .* and
explicitly requires all matching non-tide contexts to be successful; other Ring-0 stages override
this to an anchored context to avoid overbroad gating.

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/stage-ring-0-tekton-kueue.yaml[79-85]
components/kargo/internal-production/projects/kargo-infra-deployments/base/promotion-tasks/wait-for-ci.yaml[13-18]
components/kargo/internal-production/projects/kargo-infra-deployments/base/promotion-tasks/wait-for-ci.yaml[50-54]
components/kargo/internal-production/projects/kargo-infra-deployments/konflux-operator/stage-ring-0-konflux-operator.yaml[79-87]
PR-#607

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The Ring-0 tekton-kueue Stage calls the shared `wait-for-ci` PromotionTask but does not pass `requiredProwChecks`. The task defaults this to `.*`, which makes its success condition require **all** non-`tide` Prow status contexts on the commit to be present and successful.

### Issue Context
- `wait-for-ci` defaults:
 - `requiredProwChecks: ".*"`
 - Its `successExpression` filters all non-`tide` contexts matching that regex and requires they all be `success`.
- Existing Ring-0 stages in this project override `requiredProwChecks` to a specific anchored context (avoids accidental gating changes and reduces risk of waiting on unrelated contexts).

### Fix Focus Areas
- components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/stage-ring-0-tekton-kueue.yaml[79-87]
- components/kargo/internal-production/projects/kargo-infra-deployments/base/promotion-tasks/wait-for-ci.yaml[7-18]
- components/kargo/internal-production/projects/kargo-infra-deployments/base/promotion-tasks/wait-for-ci.yaml[37-54]
- components/kargo/internal-production/projects/kargo-infra-deployments/konflux-operator/stage-ring-0-konflux-operator.yaml[79-87]

### What to change
Add a `requiredProwChecks` var to the tekton-kueue Stage’s `wait-for-ci` invocation, using the intended full Prow context regex (anchored, like other ring-0 stages), e.g. `^ci/prow/<tekton-kueue-required-job>$` (and similarly adjust `requiredCheckRuns` if needed).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Stage filename mismatched 📘 Rule violation ⚙ Maintainability

Description

The manifest kind is Stage, but the filename is stage-ring-0-tekton-kueue.yaml instead of
stage.yaml. This violates the required one-kind-per-file naming convention and can cause
inconsistent manifest organization.

Code

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/stage-ring-0-tekton-kueue.yaml[R1-5]

+---
+apiVersion: kargo.akuity.io/v1alpha1
+kind: Stage
+metadata:
+  name: ring-0-tekton-kueue

Relevance

⭐ Low

Repo rejected renaming Stage files to match kind/filename convention (definitely_rejected in PR
#626, #484).

PR-#626
PR-#484

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1100 requires the Kubernetes manifest filename to match the single top-level
resource kind in the file. The added manifest declares kind: Stage, but the filename is not
stage.yaml.

Rule 1100: Name Kubernetes manifest files after single primary Kind
components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/stage-ring-0-tekton-kueue.yaml[1-5]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A Kubernetes manifest with `kind: Stage` must be named `stage.yaml` (case-insensitive, no prefixes/suffixes).

## Issue Context
The file `stage-ring-0-tekton-kueue.yaml` contains a single `Stage` resource, but its filename does not match the resource Kind.

## Fix Focus Areas
- components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/stage-ring-0-tekton-kueue.yaml[1-5]
- components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/kustomization.yaml[4-7]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. PromotionTask filename mismatched 📘 Rule violation ⚙ Maintainability

Description

The manifest kind is PromotionTask, but the filename is tekton-kueue-promote-ring-0.yaml instead
of promotiontask.yaml. This violates the required one-kind-per-file naming convention and can
cause inconsistent manifest organization.

Code

components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/promotiontasks/tekton-kueue-promote-ring-0.yaml[R1-5]

+---
+apiVersion: kargo.akuity.io/v1alpha1
+kind: PromotionTask
+metadata:
+  name: tekton-kueue-promote-ring-0

Relevance

⭐ Low

Kind-to-filename enforcement has been repeatedly rejected for Kargo manifests (e.g., Stage naming
rule rejected in PR #626).

PR-#626
PR-#484

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1100 requires the Kubernetes manifest filename to match the single top-level
resource kind in the file. The added manifest declares kind: PromotionTask, but the filename is
not promotiontask.yaml.

Rule 1100: Name Kubernetes manifest files after single primary Kind
components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/promotiontasks/tekton-kueue-promote-ring-0.yaml[1-5]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A Kubernetes manifest with `kind: PromotionTask` must be named `promotiontask.yaml` (case-insensitive, no prefixes/suffixes).

## Issue Context
The file `tekton-kueue-promote-ring-0.yaml` contains a single `PromotionTask` resource, but its filename does not match the resource Kind.

## Fix Focus Areas
- components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/promotiontasks/tekton-kueue-promote-ring-0.yaml[1-5]
- components/kargo/internal-production/projects/kargo-infra-deployments/tekton-kueue/promotiontasks/kustomization.yaml[1-5]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. Kargo overlays not CI-built 📘 Rule violation ☼ Reliability

Description

The PR changes Kustomize content under components/kargo/..., but the repo CI kustomize build
step explicitly excludes components/kargo/*, so these overlays are not validated in CI. This
violates the requirement that overlays be built successfully before submission.

Code

components/kargo/internal-production/projects/kargo-infra-deployments/kustomization.yaml[R8-12]

  - base
  - dummy-deployment
  - konflux-operator
+  - tekton-kueue
  - authentication

Relevance

⭐ Low

Team previously rejected re-enabling CI builds for excluded Kargo paths in kube-linter workflow (PR
#484).

PR-#484

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1101 requires Kustomize overlays to be built successfully and covered by CI. The
workflow’s Run kustomize build step excludes components/kargo/*, while this PR adds/changes
resources in that excluded tree.

Rule 1101: All kustomize overlays must build successfully before submission
components/kargo/internal-production/projects/kargo-infra-deployments/kustomization.yaml[7-12]
.github/workflows/kube-linter.yaml[39-45]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Kustomize overlays changed by this PR are not covered by CI builds because the current workflow excludes `components/kargo/*` from `kustomize build`.

## Issue Context
This PR adds a new resource under `components/kargo/internal-production/...`, but CI does not run `kustomize build` for any `components/kargo` kustomizations.

## Fix Focus Areas
- .github/workflows/kube-linter.yaml[39-45]
- components/kargo/internal-production/projects/kargo-infra-deployments/kustomization.yaml[7-12]
- components/kargo/internal-staging/kustomization.yaml[1-8]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[enkeefe00]

I don't think this PR should be merged yet because the Kueue component hasn't undergone the migration to the new universal component standards and new ArgoCD instances. Any promotions will fail because the referenced ring directories do not yet exist.

[openshift-ci]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.