Build Sailfish OS application using GitHub Actions or GitLab CI

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

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.

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

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

@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

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.

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:

2 Likes

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

3 Likes

Missed note:

For sfos >= 5 build you should use:
uses: coderus/github-sfos-build@sfos5

see

2 Likes

Thanks! One question, though. What’s the build target for noarch?

Fatal: ‘SailfishOS-5.0.0.43-noarch’ is not a known build target

i486 / i586, because that builds fastest on x86-64 machines “the cloud” is usually comprised of (checked to be valid on GitHub, SailfishOS-OBS etc.).

1 Like

ok, so with

- name: Build i486
  id: build_i486

???

the name and id fields can be whatever you like
for faster build with a single arch image you can use:

- name: Build
  id: build
  uses: coderus/github-sfos-build@sfos5
  with:
    release: 5.0.0.43
    arch: i486
    suffix: "-i486"

This will load a smaller build image containing only one architecture, and will be faster. In general, it doesn’t matter which arch to use to build noarch packages, i486 is faster because it has no virtualization overhead. And no, there is no “noarch architecture”, a processor cannot have no architecture. The noarch rpm suffix simply means that there are no binaries in the package.

3 Likes

Hmmm. With that suffix I get: Unable to find image ‘coderus/sailfishos-platform-sdk-486:5.0.0.43’ locally

I had on @olf 's advice tried with arch i486 but that runs into issues with setup tools (python package installs). I did have these builds running with all arches specified previously so I’m not sure what changed:
error:

python3: can't open file 'setup.py': [Errno 2] No such file or directory
 python3 setup.py install --root=/home/mersdk/build/installroot --prefix=/usr/share/harbour-happycamper/

These build on sdk and on obs.

Preeetty sure that error comes from git not checking out submodules.

Then $WORKDIR/lib/docopt will be empty, which makes qmake5_install not put anything into /home/mersdk/build/installroot//usr/share/harbour-happycamper/lib/docopt, and it fails after changing there.

Thanks for the thought :slight_smile: But, these are included:

In the pro:

libs.path = /usr/share/$${TARGET}
libs.files = lib
INSTALLS += libs

In the spec:

cd %{buildroot}/%{_datadir}/%{name}/lib/docopt
python3 setup.py install --root=%{buildroot} --prefix=%{_datadir}/%{name}/
rm -rf %{buildroot}/%{_datadir}/%{name}/lib/docopt

That worked with the older github actions (last year, 4.4, all arches specified).

It’s not about something not getting installed, it’s not there in the source tree in the first place:

From the build log:

1 Like

It is not a submodule. It is a directory included with the rest of the sources. I don’t understand how that would not be checked out?

And, yes, I have also done this with submodules and it works in a github context using @coderus 4.4 platform sdk. that’s how the harbour-tidal github action works. but, that’s not the point.

This was working 8 months ago (with a similar setup for other porjects like Solver, Plotter, etc, etc).

errr. no. you are right. I do not recall what I was doing. hmmmm.

1 Like

Humor me and try:

steps:
- uses: actions/checkout@v4
  with:
    submodules: true