In my post about Akademy 2023 I had mentioned the efforts to retire KDE’s Jenkins installation (“Binary Factory”) in favor of Gitlab on invent.kde.org. One remaining issue has meanwhile been resolved, the migration of the Craft cache jobs. And for migrating the packaging jobs there’s an easy way how you can help.

Jenkins

Jenkins has been used by KDE prior to Gitlab for CI/CD and other automation tasks, but is being phased out with all those things being unified on Gitlab. Jenkins is also still tied to Phabricator for user authentication, which is another legacy system we want to retire.

There are basically two remaining types of tasks on Jenkins:

  • Craft cache jobs. These jobs are primarily optimizations for Craft-based build jobs, so that dependencies don’t need to be built every time. Those jobs run infrequently but can take quite some time and resources to complete, with the extreme case of building QtWebEngine being a particular challenge here.
  • Jobs that build outside-facing artifacts. That includes application packages or installers (e.g. APK, Flatpak, Windows and macOS binaries, etc) but also compilation and deployment of websites and other web assets. All of those have in common that they need special permissions or access credentials to sign or deploy the results, and that’s the complicated part here.

Craft cache jobs

The Craft cache jobs have meanwhile been migrated to Gitlab. They live in the ci-management repository alongside the CI seed jobs now and use the new central Craft configuration in the ci-utilities repository which is shared with Gitlab package build jobs.

To support this two new build nodes with 128GB of RAM each have been added to the Gitlab CI system, which should be capable of building QtWebEngine without crashing and burning. Those aren’t limited to Craft cache jobs of course, but generally contribute to processing CI jobs.

Package build jobs

While the biggest challenge for migrating the package jobs remains the signing system (which is being worked on), there is however one step we can do in preparation of moving those jobs already.

Historically the manifests files for the nightly Flatpak builds were all in the central flatpak-kde-applications repository. This matched the way build jobs were managed centrally on Jenkins, but with Gitlab this is all tied to the corresponding repositories now. So the Flatpak manifests have to move there. For a bit more than half this is already done, but at the time of writing there are still about 90 left to do.

How you can help: Moving Flatpak manifests

And that’s something where everyone can help, following these steps:

  • Copy a manifest file from flatpak-kde-applications into the corresponding application repository root folder, typically named .flatpak-manifest.json there.
  • In that file, change the sources entry for the application to use the current working directory instead of a new Git checkout:
"sources": [{ "type": "dir", "path": "." }]
  • Edit the .gitlab-ci.yml file in that repository to include the Flatpak job definition:
include:
  - https://invent.kde.org/sysadmin/ci-utilities/raw/master/gitlab-templates/flatpak.yml
  • Submit a merge request with the above changes, verify there is a Flatpak job in the CI pipeline now and that it passes without errors.
  • Once that merge request is integrated, replace the original manifest in flatpak-kde-applications with a .remoteapp file with the same base name, pointing to the project repository. This ensures that the existing Flatpak nightly jobs on Jenkins remain functional until their Gitlab equivalents can publish their results in a similar convenient form as well.
ID=org.kde.example
JSON=.flatpak-manifest.json
GITURL=https://invent.kde.org/group/example.git

All that only takes a few minutes and doesn’t even require a full development setup!