Konflux + Fedora Update, May 2025

A few months ago, we moved most discussion about Fedora and Konflux to matrix, to #konflux:fedora.im and in the process, I kind of forgot to post updates to #containers-sig. Apologies! I’ve got three things to share today:

  • Usernames are now FAS usernames in the Fedora Konflux instance
  • Tekton Pipeline for building Fedora RPMs is available
  • Bootc-devel images building in Fedora Konflux

Usernames are now FAS usernames in the Fedora Konflux instance

Since the beginning, auth in the Fedora Konflux Cluster has been configured to use your FAS email address as your identity, not your FAS username. This was weird and jarring and it took us longer to solve than I expected, but it’s done now. With fedora/infrastructure/konflux/infra-deployments!5, you should now see your FAS username as your logged in identity and RBAC works with FAS usernames. Thanks to Yftach Herzog and Gal Ben Haim for figuring it out.

FAS groups don’t work yet but they’re on their way.

Tekton Pipeline for Building Fedora RPMs is available

The Fedora flavor of the Tekton RPM Build Pipeline, which allows you to build Fedora packages in Fedora Konflux, is available, thanks to effort from Pavel Raiskup.

The main difference compared to the upstream flavor is that the Fedora flavor builds against Fedora “buildroots” (RPM package repositories hosted by the official Fedora Koji build system).

How it works

In short, based on the provided parameters, the pipeline retrieves RPM package source code from a DistGit-like repository, obtains Mock configuration from Fedora Koji, and builds RPMs using Mock. The pipeline allocates architecture-specific workers to run Mock builds in the appropriate environments (aarch64 and x86_64, given the current infrastructure limitations of Fedora Konflux).

Except for a few differences (see the diff-flavor.sh script), this flavor works in principle similarly to the upstream flavor, so please refer to the upstream documentation.

How to build your Fedora RPM(s) in Fedora Konflux

There are a few integration steps you need to follow to enable RPM builds:

  1. Host your package sources in a compatible forge (currently GitHub or GitLab). For example, if you’re working with a Fedora package (hosted on Pagure, which can not be integrated with Konflux), you’ll need to create a fork in a supported forge. Here is an example repository.
  2. Enable the GitHub Konflux application for your project. For the GitLab forge, you need to set repo secret .
  3. Create an Application/Component in the Konflux UI for your package builds. Until we get the onboarding flow integrated, this will generate a pull request to your repo with a default container pipeline, which you can close and ignore.
  4. Add a .tekton/ directory to your Git project. See this pull request for reference. You’ll need to update the configuration according to your setup:
    • application/component names
    • package name
    • quay.io path where you want the pipeline to upload built artifacts
    • correct parameters
  5. Open a PR with the new .tekton/ directory → let CI complete successfully (green) → merge the PR → wait for the Tekton push pipeline run to finish the RPM build.
  6. Download the RPMs from Quay.io: using oras or podman artifact
url="quay.io/konflux-fedora/your-tenant/your-component:d8e3fd281eaf19f54a091a7df9f7a3258c73f2a2.nvr-NVR"
mkdir -p /tmp/results && cd /tmp/results && oras pull "$url"

Help the project

We’d love your feedback and contributions. Please open issues, or contribute!

Bootc-devel images building in Fedora Konflux

The bootc team has been working to get the bootc-devel images at https://quay.io/repository/bootc-devel built and published from the bootc-tenant namespace of the Fedora Konflux instance. Kudos to Miguel Martin for making this work.

One effect of this is that you can inspect the supply chain artifacts generated by the Konflux pipeline. First, get cosign and then use cosign tree to list them.

❯ cosign tree quay.io/bootc-devel/fedora-bootc-rawhide-standard:latest
📦 Supply Chain Security Related artifacts for an image: quay.io/bootc-devel/fedora-bootc-rawhide-standard:latest
└── 💾 Attestations for an image tag: quay.io/bootc-devel/fedora-bootc-rawhide-standard:sha256-233f9b9946b9e9c39255a7a8c6ac3af84d0ee37dd911bfd42fdb2cf552f924aa.att
   └── 🍒 sha256:5a61a2b4a4452a9387462aae50b220004ff3b75cc73a657c41091f5d626c2b92
└── 🔐 Signatures for an image tag: quay.io/bootc-devel/fedora-bootc-rawhide-standard:sha256-233f9b9946b9e9c39255a7a8c6ac3af84d0ee37dd911bfd42fdb2cf552f924aa.sig
   └── 🍒 sha256:9cffbce01ed8cb862b831f08dadf23aed16fbb52f825a66ffba01c519fbf49c3
└── 📦 SBOMs for an image tag: quay.io/bootc-devel/fedora-bootc-rawhide-standard:sha256-233f9b9946b9e9c39255a7a8c6ac3af84d0ee37dd911bfd42fdb2cf552f924aa.sbom
   └── 🍒 sha256:8a5aa43e7e277ecb4eb8110fad0011d8760f6dbf5086019b4871304f670a50dc

Use cosign download sbom … to look at the SPDX SBOM:

❯ cosign download sbom --platform linux/amd64 quay.io/bootc-devel/fedora-bootc-rawhide-standard:latest 2> /dev/null \
| grep pkg: | sed 's/^ *//' | head
"referenceLocator": "pkg:oci/fedora-bootc-rawhide-standard@sha256:11da43bbea095dccdbb2103e24471bc250508b40d756e7e5baf719114593f6d7?repository_url=quay.io/konflux-fedora/bootc-tenant/fedora-bootc-rawhide-standard",
"referenceLocator": "pkg:rpm/fedora/ModemManager-glib@1.22.0-5.fc42?arch=x86_64&distro=fedora-43&upstream=ModemManager-1.22.0-5.fc42.src.rpm"
"referenceLocator": "pkg:rpm/fedora/NetworkManager@1.53.1-1.fc43?arch=x86_64&distro=fedora-43&epoch=1&upstream=NetworkManager-1.53.1-1.fc43.src.rpm"
"referenceLocator": "pkg:rpm/fedora/NetworkManager-cloud-setup@1.53.1-1.fc43?arch=x86_64&distro=fedora-43&epoch=1&upstream=NetworkManager-1.53.1-1.fc43.src.rpm"
"referenceLocator": "pkg:rpm/fedora/NetworkManager-libnm@1.53.1-1.fc43?arch=x86_64&distro=fedora-43&epoch=1&upstream=NetworkManager-1.53.1-1.fc43.src.rpm"
"referenceLocator": "pkg:rpm/fedora/NetworkManager-tui@1.53.1-1.fc43?arch=x86_64&distro=fedora-43&epoch=1&upstream=NetworkManager-1.53.1-1.fc43.src.rpm"
"referenceLocator": "pkg:rpm/fedora/WALinuxAgent-udev@2.13.1.1-1.fc43?arch=noarch&distro=fedora-43&upstream=WALinuxAgent-2.13.1.1-1.fc43.src.rpm"
"referenceLocator": "pkg:golang/_/builddir/build@v0.1.1#BUILD/toolbox-0.1.1-build/toolbox-0.1.1/src"
"referenceLocator": "pkg:rpm/fedora/aardvark-dns@1.15.0-1.fc43?arch=x86_64&distro=fedora-43&epoch=2&upstream=aardvark-dns-1.15.0-1.fc43.src.rpm"
"referenceLocator": "pkg:rpm/fedora/acl@2.3.2-3.fc42?arch=x86_64&distro=fedora-43&upstream=acl-2.3.2-3.fc42.src.rpm"
...

Use cosign download attestation … to look at the SLSA provenance attestation.

❯ cosign download attestation  quay.io/bootc-devel/fedora-bootc-rawhide-standard:latest \
| jq '.payload | @base64d | fromjson | .predicate.materials' | head -13
[
  {
    "digest": {
      "sha256": "2474cc2cd84db2bc0abe595d35a878d01af3bf8783aac0ccc252c9a7a00d8271"
    },
    "uri": "quay.io/bootc-devel/tekton-catalog/pipeline-buildah-build-bootc-multi-platform-oci-ta"
  },
  {
    "digest": {
      "sha256": "75c6ac42431e29465eba3ff3367a18416722cdc18cb7c5745b448f199082fdef"
    },
    "uri": "oci://registry.access.redhat.com/ubi9/skopeo"
  },
2 Likes

Ah good, testable rpm packaging support for people to use and provide feedback on.

I realize that the lack of integration right now with pagure is probably a significant hurdle to test some packaging workflows, but if would be great if packagers could test this out as soon as this weekend, with an eye towards giving feedback at flock. I would but I’m still coming back up to speed on rpm packaging myself, so my perspective is probably of limited value compared to some active proven packagers.

Naively I would think that some of the more complicated workflows (chainbuilds and other things) will be hard to throw at this until there is fedora git forge integration. But if someone figures out how to test more complicated workflows with this setup, sooner is better than later for feedback.

@ralph, apologizes, I think I remember you pointing me to a conceptual rawhide rpm packaging workflow and I can’t find the link. Can you repost that. It would be interesting for packagers who want to test rpm building to see how well their experience matches/diverges from the idealized workflow. Hopefully that idealized workflow can be an initial shared mental model frame of reference for workflow discussions that come out of the testing.

1 Like

Ah, you’re thinking of fedora / Fedora Infrastructure / Konflux / workflows · GitLab

1 Like

Nice work! I know a lot of effort has gone into this and I’m looking forward to modernizing parts of the build process here.!

This part is very interesting! A lot of relationship to build system dependency management / lockfile support · Issue #833 · rpm-software-management/dnf5 · GitHub

2 Likes