Skip to content

Proposing Flatpak CI builds and Adding script

Snehit Sah requested to merge (removed):flatpak into master

Edit (May 28, 2022) : This description is probably not accurate anymore, considering the many changes this merge request went through.

Background

During Season of KDE 2022, I took up the task of improving Flatpak related stuff for KDE. One of the goals is to introduce Flatpak CI builds for KDE applications.

The intention of this merge request is to share my work with the CI sysadmin folks, get reviews and eventually, have this merged.

Short description

Currently, we have CI builds for FreeBSD and OpenSuse on most repositories that run on every merge request and push. But such an arrangement does not exist for Flatpak. With more and more KDE applications being published to Flathub, having Flatpak CI buids on KDE Invent will let project maintainers spot issues quicker and fix them before the Flatpak packaging team updates applications on Flathub, thus reducing surprises when packaging.

Solution

Add Flatpak CI :)

I would propose having Flatpak CI builds on every push and merge request, quite similar to the way we have it for other platforms right now.

I have worked on a small script that will build and install application. This script will be run as a part of GitLab Pipelines.

To start off, my script is housed on GitLab account for now. https://gitlab.com/flyingcakes/ci-script

The files of interest are deps-build-v2.yml and deps-build-v2 which correspond to gitlab-templates/flatpak.yml and flatpak-build.py respectively in this merge request.

Getting this on KDE Invent

The inclusion will have to be done in three steps.

  1. First we will have to add the Flatpak container on the CI Images repo. The Dockerfile for my container is on my GitHub repository : flyingcakes85/fedora-flatpak-docker
  2. Next, we add the GitLab CI file to CI Utilities repo, i.e. this merge request
  3. Finally, applications that want to enable Flatpak CI builds will have to add a short snippet to their .gitlab-ci.yml file. (Described later in this merge request)

As an initial test run, I suggest we add the to a limited number of applications, to see how it fares in real world usage. During this time, I can update the script to get around any issues we discover. Later on when the script is mature enough, we can have it in wider selection of applications.

More about my script

This information is lifted off of the readme I put up on the GitLab repository. The preparation step in this merge request slightly differs from the one on my GitLab, but script logic is same.

Using

To use this in your KDE application, follow these steps

  1. Ensure the Flatpak manifest for your application is there on Flatpak KDE Applications repo. Manifests may be Remote app, JSON or YAML file.
  2. Add the following include in your application repository's .gitlab-ci.yml 
include: 'https://gitlab.com/flyingcakes/ci-script/-/raw/main/deps-build-v2.yml'

PS. This include link will refer to this repo once this merge request is accepted.

  1. Add this block in your application repository's .gitlab-ci.yml 
flatpak:
 extends: '.flatpak'
 variables:
 FILE_NAME: org.kde.filename
 MODULE_NAME: module
 APP_ID: org.kde.appid

FILE_NAME is to be set to the name of file of your application's manifest in Flatpak KDE Applications repo. Make sure to add the right extension. Eg.

FILE_NAME: org.kde.kdiff3.json

MODULE_NAME is the name of your application's module in the manifest. Eg.

MODULE_NAME: kdiff3

APP_ID is the name with which your application bundle will be created post successful build. Eg

APP_ID: org.kde.kdiff3

Deployments

To test this script, I have deployed it on these repositories

  1. KDiff3
  2. Kronometer

Working

  1. The entry point is in gitlab-templates/flatpak.yml. It starts a docker container and fetches the KDE CI utilities repository.
  2. The python script takes over to build the application.
  3. First it checks if the manifest is a remote application. In that case, it updates manifestfile location accordingly. (We assume that the remote GITURL points to the application source code, so we don't fetch the repository again). If manifest is a JSON or YAML file, this step is skipped.
  4. Next, the manifest is edited to use local directory as the build source. (rather than the git repository on website)
  5. Application is now built. After successful build, python script exits.
  6. Back in gitlab-templates/flatpak.yml, it prepares artifacts and uploads it. These artifacts can be downloaded by maintainers to test the application.

CC @ravier

Edited by Snehit Sah

Merge request reports