Liri Blog

Updates for April, 2020


Photo by Glen Carrie on Unsplash

April didn’t see much code improvements, it was pretty much dedicated to the continuous integration.

Previously we used Travis CI and AppVeyor as continuous integration for pushes and pull requests, and Jenkins to build the OSTree repository, OS images and translation updates.

Now with GitHub Actions we can really improve the Liri CI.

GitHub Actions introduce the concept of workflows, this gives us great flexibility to implement whatever we want.

We now have basically three workflows:

  • Status check and validation
  • Build and release
  • Translations

We can see if each commit or pull request has valid QML and files (desktop entries and AppStream metadata) with the following actions that I developed for Liri and will be in the marketplace soon:

And also prevent work in progress pull requests to be merged.

In the future we can also check for the proper SPDX license information or whether there are coding style violations.

With the build workflow we can check if the code builds on different operating systems, platforms and compilers. The cross-platform apps benefit by this the most as we can build against different Qt versions, Linux, Windows, macOS and Flatpak. In the future we’ll probably add Snap and AppImage. The resulting artifacts are available for each run of the workflow. When a new version is released, the artifacts are attached to the release automatically.

When a library is built in the CI, the workflow stores a .tar.gz artifact with the binaries that will be used by the CI of another repository that depends on that library. Given that you cannot download artifacts from another repository with the official actions/download-artifact, I made my fetch-artifact action.

Every week the translation sources are regenerated and sent to Transifex. The translations, now rebased to the new sources, are downloaded and automatically committed. This was previously done in our private Jenkins installation, but the workflows are easier to configure and manage. This also result in less work on our private build server.

These are the actions I made for the translations:

Then I made the .github repository that contains default GitHub files, the so called community health files such as code of conduct, contributing guidelines, issue template and pull request template. This is yet another step towards a better GitHub integration.