Status update: Adding CI Pipelines on GitLab - post #5

⌂ home      ⇧ one level up
Tue Mar 29, 2022 · 1526 words · 8 min
Tags :  sok-2022 kde planet-kde
Toggle table of contents

Hey there!

This is my fifth status update for Season of KDE 2022.

This time, I have updates on the automation side of things. I got a preliminary version of the required GitLab pipelines working.

Pipeline for Updating Manifests

I got my hands dirty with Docker and added the Flatpak External Data Checker image over on Quay. The image was used over on my Gitlab repositories. This let me run "actions", similar to what we have on GitHub, but on GitLab too. Since we're not relying on the official FEDC image, I can control what all goes into the image and add extra dependencies that would be required. (like curl)

Currently, the script is in bash. I plan to port it to Python, as it will be much easier to maintain and work with.

The script is expected to loop through all manifests in the repository and run FEDC on each one of them while capturing FEDC output to detect which packages have been updated. It then does some cleanup and sorts it to get the final list. With all the changes, it will finally commit and create a merge request over on the repository. To avoid creating multiple merge requests for the same set of updates, the script will check if there is an existing merge request already. To help in this, it adds a short hash in the merge request title, which lets it cross-check the set of updates and decide whether to create a new merge request or not.

The repository can be found here -> https://gitlab.com/flyingcakes/kde-flathub-master. Actual update script is in the updater.sh file in this repo.

Pipeline for Application CI

To goal here is to do a Flatpak build for KDE applications whenever they receive a new commit or merge request. We currently have similar CI pipelines running, but they are only for FreeBSD and OpenSuse. I plan to add a third job there, which will build the application inside Flatpak environment, and provide a way to install and test those builds on a local machine.

The inspiration for this has been taken from similar pipelines that run on Gnome GitLab. In essence, on every run, we fetch the application's Flatpak manifest, replace its source link with the latest commit and try a build. If the build succeeds, we upload its .flatpakref file as an artefact.

My implementation for this is still in an alpha phase and will need some more work to become viable for regular use on KDE applications.

The testing repository for this can be found here -> https://gitlab.com/flyingcakes/kdiff-v2/

Follow up on Checker Data Additions on GitHub

In my last post, I described how I'm adding checker data to manifests hosted on GitHub. I have added the data to most applications. The bigger ones like Krita and KdenLive are still missing data. This should be fixed in due time.

We noticed some issues with it, which seems to be related to FEDC itself. It sometimes creates repeated pull requests for the same package.

Other issues were caused because I had inadvertently provided wrong links in checker data.

None of the issues caused any inconvenience though. The maintainers have been thoroughly verifying pull requests to ensure nothing unexpected goes into the actual application. I fixed those minor issues as and when we got to know about them.

Adding checker data

Other minor fixes

hire me! · blog · about · resume · github · kde invent · endeavour · email · home

🪻🌼