Migrate MVO FBC pipelines to release-branch triggers

[osmman]

Summary

• Replace push+PR pipelines with push-only, release-branch triggers
• Drop v4.15, add v4.22
• Add model-validation-operator to catalog sync workflow
• Single application label (mvo-fbc) across all versions

Companion PR: securesign/pipelines#521

Resolves: SECURESIGN-4331

🤖 Generated with Claude Code

[qodo-for-securesign]

PR Summary by Qodo

Migrate MVO FBC pipelines to release-branch push triggers
⚙️ Configuration changes 🕐 20-40 Minutes

Description

• Switch MVO FBC Tekton triggers from main-only to push-only on release-* branches.
• Remove per-version PR PipelineRuns and standardize on a single mvo-fbc application label.
• Add model-validation-operator to the catalog sync workflow package allowlist and introduce v4.22.

Diagram

graph TD
  A["GitHub push event"] --> B{"CEL: target_branch matches release-*?"} --> C["MVO FBC PipelineRuns\n(v4.16-4.22)"] --> D["pipelines repo\n(fbc-builder)"] --> E["Quay images\n(mvo-fbc-v4.xx)"]
  F["GitHub Actions\nsync-catalog"] --> G["SUPPORTED_PACKAGES\n(+ model-validation-operator)"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Single templated PipelineRun + version param

• ➕ Reduces duplicated YAML across v4.16–v4.22
• ➕ Makes trigger/label changes one-time instead of N-times
• ➖ Requires introducing/standardizing a parameterization pattern and possibly additional tooling
• ➖ Harder to review if it involves larger refactors across existing CI conventions

2. Keep PR validation but narrow scope (e.g., manual/label-based)

• ➕ Retains early feedback on PRs without running on every change
• ➕ Can be used for risky catalog changes before merging to release branches
• ➖ Adds operational complexity (labeling/manual triggers) and more CI surface area
• ➖ May conflict with the goal of push-only release branch builds

Recommendation: The PR’s approach (push-only + release-* gating) is the lowest-risk migration because it mostly changes CEL predicates and labels while keeping the underlying build pipeline (fbc-builder) intact. Consider a follow-up to consolidate per-version PipelineRuns via templating/parametrization once the migration is stable.

Files changed (8) +43 / -34

Other (8) +43 / -34

sync-catalog.yamlInclude model-validation-operator in catalog sync allowlist +1/-1

Include model-validation-operator in catalog sync allowlist

• Extends SUPPORTED_PACKAGES to add model-validation-operator to the catalog sync workflow. This allows the sync job to process that package alongside existing operators.

.github/workflows/sync-catalog.yaml

mvo-fbc-v4-16-push.yamlTrigger v4.16 builds on release-* pushes and unify application label +5/-4

Trigger v4.16 builds on release-* pushes and unify application label

• Updates Pipelines-as-Code CEL to run only on push events targeting release-* branches with relevant path changes. Standardizes appstudio.openshift.io/application to mvo-fbc (component remains version-specific).

.tekton/mvo-fbc-v4-16-push.yaml

mvo-fbc-v4-17-push.yamlTrigger v4.17 builds on release-* pushes and unify application label +5/-4

Trigger v4.17 builds on release-* pushes and unify application label

• Switches the CEL trigger from main-only to release-* branch pushes and adjusts the pathChanged glob to **. Changes the application label to the shared mvo-fbc value.

.tekton/mvo-fbc-v4-17-push.yaml

mvo-fbc-v4-18-push.yamlTrigger v4.18 builds on release-* pushes and unify application label +5/-4

Trigger v4.18 builds on release-* pushes and unify application label

• Moves to a multiline CEL expression that gates on push + release-* and relevant path changes. Normalizes the application label to mvo-fbc for cross-version grouping.

.tekton/mvo-fbc-v4-18-push.yaml

mvo-fbc-v4-19-push.yamlTrigger v4.19 builds on release-* pushes and unify application label +5/-4

Trigger v4.19 builds on release-* pushes and unify application label

• Updates trigger logic to push-only on release-* branches with simplified pathChanged globbing. Sets appstudio.openshift.io/application to mvo-fbc while keeping the versioned component label.

.tekton/mvo-fbc-v4-19-push.yaml

mvo-fbc-v4-20-push.yamlTrigger v4.20 builds on release-* pushes and unify application label +5/-4

Trigger v4.20 builds on release-* pushes and unify application label

• Replaces main-branch gating with release-* regex matching for push events and updates the pathChanged glob to **. Updates the application label to mvo-fbc for consistency.

.tekton/mvo-fbc-v4-20-push.yaml

mvo-fbc-v4-21-push.yamlTrigger v4.21 builds on release-* pushes and unify application label +5/-4

Trigger v4.21 builds on release-* pushes and unify application label

• Converts CEL trigger to push-only on release-* branches and updates glob patterns to ** for pathChanged. Standardizes the application label to mvo-fbc.

.tekton/mvo-fbc-v4-21-push.yaml

mvo-fbc-v4-22-push.yamlAdd v4.22 PipelineRun and retire v4.15 naming/params +12/-9

Add v4.22 PipelineRun and retire v4.15 naming/params

• Repurposes the prior v4.15 PipelineRun definition into a v4.22 build: updates name, labels, service account, path-context, output image, and adds ocp-release-version=v4.22. Also updates the trigger to push-only on release-* branches.

.tekton/mvo-fbc-v4-22-push.yaml

[qodo-for-securesign]

Code Review by Qodo

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

1. Sync requires seeded catalog 🐞 Bug ☼ Reliability

Description

The sync-catalog workflow now includes model-validation-operator, but its sync step calls
utils/render_catalog.sh with CATALOG_FILE pointing to
$OCP_VERSION/$PACKAGE_NAME/catalog/$PACKAGE_NAME/catalog.json, and render_catalog.sh reads that file
with jq before generating output. If a newly-added package/version has no pre-seeded catalog.json
(or the catalog/ directory tree), the workflow will exit non-zero and fail the catalog update for
that OCP version.

Code

.github/workflows/sync-catalog.yaml[9]

+  SUPPORTED_PACKAGES: "rhtas-operator|policy-controller-operator|model-validation-operator"

Relevance

⭐⭐⭐ High

Team recently accepted bootstrapping/handling missing seed catalog files to prevent workflow exits
(PR #329).

PR-#329
PR-#311

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow now selects packages by regex based on SUPPORTED_PACKAGES and then unconditionally
calls render_catalog.sh with a catalog.json path under each $OCP_VERSION/$PACKAGE_NAME directory;
render_catalog.sh runs with set -euo pipefail and uses jq to read $CATALOG_FILE before writing
it, so missing files/directories will cause an immediate failure. This is the same missing-file
failure pattern previously accepted in PR #329.

.github/workflows/sync-catalog.yaml[8-9]
.github/workflows/sync-catalog.yaml[54-77]
utils/render_catalog.sh[1-33]
PR-#329

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 catalog sync workflow invokes `./utils/render_catalog.sh` with a `CATALOG_FILE` path under `$OCP_VERSION/$PACKAGE_NAME/catalog/$PACKAGE_NAME/catalog.json`, but `render_catalog.sh` immediately runs `jq` against `"$CATALOG_FILE"` before (re)generating it. This makes the workflow non-bootstrappable for any package/version that does not already have `catalog.json` (and parent directories) committed.

### Issue Context
This PR expands `SUPPORTED_PACKAGES` to include `model-validation-operator`, increasing the chance that the sync job encounters a package/version that hasn't been seeded yet.

### Fix Focus Areas
- .github/workflows/sync-catalog.yaml[54-77]
- utils/render_catalog.sh[1-33]

### Implementation notes
- In `sync-catalog.yaml`, create the expected directory structure before writing files, e.g.:
 - `mkdir -p "$OCP_VERSION/$PACKAGE_NAME"`
 - `mkdir -p "$OCP_VERSION/$PACKAGE_NAME/catalog/$PACKAGE_NAME"`
- In `utils/render_catalog.sh`, handle first-run bootstrap safely:
 - If `"$CATALOG_FILE"` does not exist, set `related_images` to `{}` (or skip the preservation logic) instead of running `jq` on a missing file.
 - Ensure `mkdir -p "$(dirname "$CATALOG_FILE")"` before redirecting output to `"$CATALOG_FILE"`.
- Keep behavior identical for already-seeded package/version directories.

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

---