F44 Change Proposal: Build FCOS on Fedora Konflux [SelfContained]

Project Discussion Change Proposals
, ,
1

Build Fedora CoreOS on Konflux

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

We want to build Fedora CoreOS updates payloads in Konflux, instead of Jenkins.

Owner :open_book:

Detailed Description :open_book:

In F43 we switched Fedora CoreOS to be built with podman via a Containerfile. We can now leverage this to move our builds into the Fedora Konflux cluster.

Feedback :open_book:

None right now.

Benefit to Fedora :open_book:

The main benefit is the distribution of the SBOMs and attestations of the built artifacts to the end user. One will have the ability to verify how the OS was generated from the source code to the distribution.

Another nice side effect is that Konflux keeps the intermediate builds artifacts in a public namespace, which makes reproducing tests failures and debugging easier for the Fedora CoreOS maintainers.

Furthermore, this reduce the load on the Fedora CoreOS Jenkins pipeline, which is currently maintained by the CoreOS team. This will also increase the amount of shared code between CoreOS and bootc, helping with maintenance and exercising the code more.

Scope :open_book:

  • Proposal owners:
    • Will switch Fedora CoreOS production streams (stable, testing, next) to be built in Konflux. This change was already done for our rawhide builds as an experiment. Proposal owner will also replace their current custom osbuild pipeline with bootc-image-builder. Theses changes are purely contained in the pipeline, they do not change the content of the produced artefacts compared to now. Notably, the Konflux release pipeline must integrate with the fedora message bus to get the artifact signed before release.
  • Release engineering:
    • Enable selected projects to sign artifacts from Konflux pipelines using Fedora signing keys.
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact :open_book:

There should be no impact for users as the product of the new pipeline (container images, disk images) should be identical.

Early Testing (Optional) :open_book:

N/A

How To Test :open_book:

The testing artifacts builds with Konflux are currently published in coreos-devel.

One can rebase a Fedora CoreOS system to it with:

rpm-ostree rebase ostree-image-signed:docker://quay.io/coreos-devel/fedora-coreos:stable --reboot

And observe no functional difference.

Note that the automatic updates won’t work because the image is not from the official release repo.

User Experience :open_book:

No visible change for users.

Dependencies :open_book:

Contingency Plan :open_book:

  • Contingency mechanism: The Jenkins pipeline will stay in place as we will rollout this progressively across Fedora CoreOS streams. We can revert to use the historical Jenkins pipeline at any time.
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)

Documentation :open_book:

See: Migration to Konflux for a Secure FCOS Release Supply Chain - Phase 1 · Issue #2031 · coreos/fedora-coreos-tracker · GitHub

Release Notes :open_book:

Fedora CoreOS images are now built into the Fedora Konflux Cluster.

Last edited by @hricky 2026-01-26T19:22:32Z

Last edited by @hricky 2026-01-26T19:22:32Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Is “Fedora Konflux” a specific Konflux instance? Does that run in Fedora infra?

4

It’s a dedicated instance of Konflux for Fedora:

I don’t know if it runs “in” the Fedora infra however. @ralph Do you have more details?

1 Like
5

The command from the How to Test section of the proposal will fail with the following error:

error: Updates and deployments are driven by Zincati (zincati.service)
See Zincati's documentation at https://github.com/coreos/zincati
Use --bypass-driver to bypass Zincati and perform the operation anyways

The message is descriptive and clear, but to avoid it, the command can be modified as follows:

rpm-ostree rebase ostree-image-signed:docker://quay.io/coreos-devel/fedora-coreos:stable --bypass-driver --reboot

As stated, automatic updates will not work, but manual updates can be performed using the following command:

rpm-ostree upgrade --bypass-driver
6

Unless something has changed, it’s running in AWS. It is a seperate
instance, managed in the public via PR’s/gitops.

2 Likes
7

Can you describe (or just link, if there’s existing docs) how this works, and in particular how key handling works compared to the current scheme? (I remember that there was some technical difficulties with that, but not the details…)

8

This is news to me, because no Fedora strategy document has even mentioned Konflux, and the existing discussion about Konflux did not indicate any reasonable alignment with the needs from the Fedora community.

9

It was discussed in Making sure you're not a bot!, the only option that was proposed so far is Support for signing container images using cosign and self managed keys · Issue #49 · fedora-infra/siguldry · GitHub. Though, I have no idea of the ETA of that solution.

10

AIUI, this discussion is scoped to Konflux as build system for RPMs.
In the case of Fedora bootc derivatives e.g: Fedora CoreOS, Atomic Desktop - as they are designed around containers technology (tooling, workflow, etc), Konflux fits well I’d say.
That said, I’m not sure other Fedora projects would beneficiate it. Should we remove the Fedora Strategy section to not mislead ?

1 Like
11

Yes, please remove it, it doesn’t apply in this context.

1 Like
12

This change proposal has now been submitted to FESCo with ticket #3546 for voting.

To find out more, please visit our Changes Policy documentation.

13

I think we need to reach a consensus on the approach to take for signing. See comments in:

14

I reached out to @jcapitao & @jbtrystram about the disk image part of this change at it will likely not be ready in time for F44 and they decided to remove it from this proposal: Changes/Build FCOS on Fedora Konflux: Difference between revisions - Fedora Project Wiki.

15

Update on this: This is not an issue for FCOS builds as the container images are currently signed with the current process that uses GPG underneath.