Build Sailfish OS application using GitHub Actions or GitLab CI

Applications
#9

I mean testing not in the %test phase of the spec/rpmbuild, but after the rpms are generated, install whatever they contain and run it.

For example, if my app brings a systemd unit or timer, or a CLI program or script, see if it works correctly. E.g. I have a build of ImageMagick. I also have a script which uses a set of test image data and can run the convert tool from IM to check all supported file types work correctly.

So I would like to create a (gitlab) pipeline which does build -> install -> run test script. But I have not been able to get zypper to install my built RPMs, because it expects packages to reside in a proper repo. And plain rpm won’t work because it doesn’t resolve runtime dependencies.

So I guess my question boils down to:

  1. How to I transform a set of self-built RPMs into a “repo” that the local zypper on the build machine can use, but still pull dependencies from the official repos
  2. Given that repo is available, how do I transport said repo from one (GitlabCI) “task” to the next, as new docker instances are booted for each task (something about the cache and dependencies keywords in GitlabCI)
  3. Is it even smart to run applications on the build image, are tests there representative of the environment on “real” SFOS devices?
#10

I should look in to gitlab at some point, but seeing as Jolla seems to be moving back to GitHub, and it being much bigger, it’s nice that it works there to.

Hmm, you are probably right… But something is taking a whole lot of time already before the build starts. And at least in theory GitHub only gives you a limited number of minutes each month, so if that could have been improved, it would have been nice. Not to mention that humans are impatient by nature :slight_smile:

I just got enough bits to resurrect my old computer as a build server, and it builds SeaPrint in 36 seconds, quite a bit better better than GitHub CI, and mostly in the startup part.

#11

well, you cannot install application into SDK anyway… there is no point on doing that

#12

Not doubting you, but calling mb2 for building will install build dependencies. Calling zypper in a script will also install things. Why can’t I install self-built packages as well?

Mind you, I’m not talking about actually full-fledged apps requiring GUI/lipstick/silica/QML and interactive user input. Just running regular binaries and scripts in a SFOS environment.

#13

yeah i was talking about gui apps. for cli/libraries you can try to install packages into sdk to test.

#14

I tried enabling a github action for telepathy-tank to test this out. Unfortunately it needs a dependency to be build first, how would I do that? Add another github action for the dependency and then somehow fetch the artifact?

1 Like
#15

Create repo for ci with multiple submodules

#16

By repo you mean github project? Can this then be run automatically for each PR on the original project?

Do you have an example?

#17

You’ll need to push submodule update anyway, so

But there are some tricks you can do: https://github.community/t/triggering-by-other-repository/16163/2

2 Likes
#18

@vlagged reminded me of this today and I’m happy to report it still works like a charm!

1 Like
#19

Can also be used with docker images directly: harbour-bitsailor/build.yaml at master · RikudouSage/harbour-bitsailor · GitHub

3 Likes
#20

I just noted that this appears to generate a release? Your example is triggered by a v tag being made? The example I built, runs on release.

#21

Yep. It builds the apps for every commit but for a tag that starts with v (as in v1.0.0 etc.) it also creates a release where it attaches the built apps.

1 Like
#22

Ok, thanks! Nice build file. I need something in between :slight_smile: I’m one of those people that pushes too much :slight_smile: Need to look at the Action docs.

#23

you can create second workflow to build and publish release and run it manually

#24

I just read through the actions docs. I came up with:


name: Build RPMs

on:
  release:
    types: [published]
    tags:
      - '1.1*'
    branches:
      - master

Where the tag condition is just used to attach the rpms to the release. I’m surprised you can do all this in the free tier!

Now, to build a webhook to get obs chum:testing to fire a rebuild :slight_smile:

1 Like
#25

@Rikudou_Sennin, thank you for sharing your improvements over Coderus’ original version.

I went the opposite direction and overhauled the CI workflows with the intent to streamline them.

My current examples are:

1 Like
#26

I never was able to successfully utilise web-hooks at the SailfishOS-OBS (I tried about a year ago).
Did you, or anybody else?

If not, it may make sense to ask @lbt as the principal SailfishOS-OBS administrator, if web-hooks currently should be working from his perspective.

#27

Webhooks should work with something like here:

  <service name="webhook">
    <param name="repourl">https://github.com/sailfishos/gst-plugins-base.git</param>
    <param name="branch">master</param>
  </service>

And configure https://webhook.sailfishos.org/webhook/ as git-hub/lab/berg hook.

See @lbt’s explanation here Community OBS - Refurbished and re-floated - #22 by lbt

Maybe the https://webhook.sailfishos.org/webhook does not work anymore (as build.sailfishos.org doesn’t now, either), and you need to set it up as https://webhook.merproject.org/webhook :-S :question:

1 Like
#28

Thank you!

BTW, both work fine (in the browser and as webhook target), https://webhook.sailfishos.org/webhook/ and https://webhook.merproject.org/webhook/, but omitting the trailing slash (/) made me curse for half an hour.
In contrast to that, out of https://build.sailfishos.org/ and https://build.merproject.org/ only the latter works for many months, and both https://bugs.sailfishos.org/ and https://bugs.merproject.org/ are unreachable for long.

At the SailfishOS-OBS it is sufficient to provide the OBS-user cibot with maintainer privileges on package level, not necessarily on project level (if you want that), either by clicking in the User tab or inserting <person userid="cibot" role="maintainer"/> in the Meta tab right after the description section.

As nobody has written anything about the format in which events should be sent to the SailfishOS-OBS webhook interface, yet: “WWW form URL-encoded” (x-www-form-urlencoded) works (which is the default at GitHub), but JSON needs more testing to be sure. This is useless side info for most, but if one fails to utilise the webhook mechanism and is desperate to determine why (like me for 30 minutes), that is good to know.
Edit: Jolla’s documentation was vastly enhanced since i looked at the topic webhooks long ago and covers that well: Webhooks | Sailfish OS Documentation

2 Likes