I think you're interpreting the situation correctly. Upstream, we documented a decision to build those artifacts from source in https://konflux-ci.dev/architecture/ADR/0046-common-task-runner-image.html, discussed https://github.com/konflux-ci/architecture/pull/217. Downstream in RH, we're tracking the related work to actually do it in https://issues.redhat.com/browse/KONFLUX-5564 (the JIRA project isn't open atm, but we intend to make it so; that's underway). It isn't explicitly called out that we'll build against Fedora binaries or on Fedora infrastructure there; with the current plan we'll be building it in Konflux on Red Hat infrastructure, some things against ubi and and some against fedora.
With that plan, you'd end up with a task runner image that is an upstream Konflux binary. A straightforward rebuild of that upstream task runner image on the Fedora cluster, so that you have your own binary, is possible. (Same goes for all other Konflux images.) If that's what we end up wanting to do, I'd use this pattern for it to try to keep the maintenance burden low: https://konflux-ci.dev/docs/patterns/git-submodules/. I wonder where and how we would draw the line between things to rebuild for the Fedora instance and situations where you accept a third-party binary? For example, we currently deploy on a Red Hat Openshift cluster (ROSA). Rebuilding all of those openshift images is surely a step too far, no? -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
