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.
Ok, thanks! Nice build file. I need something in between Iâm one of those people that pushes too much
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
@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:
-
Simple variant using Coderusâ
coderus/github-sfos-build
GitHub-action: harbour-storeman/.github/workflows at master ¡ storeman-developers/harbour-storeman ¡ GitHub -
Slightly more Complex variant with
mb2
call inside Coderusâ docker images: patchmanager/.github/workflows at master ¡ sailfishos-patches/patchmanager ¡ GitHub
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
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
Missed note:
For sfos >= 5 build you should use:
uses: coderus/github-sfos-build@sfos5
see
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.).
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.
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 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:
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.
Humor me and try:
steps:
- uses: actions/checkout@v4
with:
submodules: true