Goal The Release Engineering team's core mission is to deliver software to customers in a reliable, repeatable, secure, and predictable manner, owning the "last mile" of the software development lifecycle. The Konflux migration necessitates rebuilding critical product-related logic, including pipeline triggering (not from webhooks), versioning, and image coupling. This epic aims to establish a robust and flexible Build Trigger Scheduler to automate and manage these critical functionalities, enabling the team to ensure consistent, predictable, and scalable delivery of software products despite the complexities of the new Konflux platform.

User Stories

• As a Release Engineer, I want to automatically trigger Konflux pipelines based on detected upstream code changes, predefined schedules, or specific events, so that I can reliably manage the end-to-end multi-channel release process for our diverse product portfolio, including nightly, candidate, and stable promotions, with zero human touch where appropriate.
• As a Release Engineer, I want to dynamically control and inject parameters for image versioning, tagging, and deployment across different Konflux clusters or tenants, so that I can ensure internal consistency for our complex products (e.g., across 70+ images on multiple architectures and 8+ release branches), meet specific security requirements (like CVE embargoes), and optimize build capacity and access control.

Non-Requirements

• Full replacement of Konflux's native pipeline event listeners or basic triggering mechanisms: This epic focuses on creating a custom, advanced triggering solution for scenarios where Konflux's built-in capabilities are insufficient, rather than replacing the core platform functionality.
• Automatic CSV (Comma Separated Values) building for the bundle registry: Konflux currently treats operator bundles as generic container images and does not provide special support for generating CSVs out-of-the-box, unlike legacy systems like Cass.
• Direct migration or porting of CPaaS midstream or Cass tagging logic: The new scheduler will implement its own logic for Konflux, not directly replicate the internal mechanisms of deprecated build systems.
• Development of a new user interface for end-to-end release flow visualization: While a comprehensive view of the release process is desired, this epic's scope is confined to the triggering and scheduling logic, with tools like Kargo being considered for broader release management and visualization.

Notes

• The implementation will involve creating a trigger controller or webhook proxy to intercept and process incoming events (e.g., Git webhooks, cron jobs).
• A key challenge is porting the logic from CPaaS that determined when to trigger a build based on upstream changes, which previously involved "poll upstream" jobs and merge requests.
• The scheduler must implement custom image tag management and versioning logic because Konflux does not provide the precise control over tags that is required for internal consistency across complex products.
• The architecture should support a multi-cluster strategy to segregate build types (e.g., downstream PR builds vs. product builds) and manage capacity, potentially involving a mechanism to calculate the "best available cluster" for a given pipeline run.
• The Kargo continuous release and promotion controller is being considered as a complementary tool to manage the subsequent stages of the release process, such as moving "frights" (commits, images) through different stages based on image tags and state machines.
• This re-implementation and architectural shift represents a substantial development workload for the Release Engineering team, and collaboration with other teams (e.g., ACM, OpenShift) that have faced similar Konflux onboarding challenges is crucial to avoid redundant effort.