Add freebsd runner

[bynect]

No description provided.

[bynect]

since the freebsd is in a vm it takes a very long time to run. I am thinking of making it a manual trigger

[bynect]

the freebsd runner takes 2.30 minutes on average, compared to the 30 seconds for linux distros...
maybe it's not too much after all

anyway, I adapted the code to work with Freebsd using coreutils. we may want to remove gnu specific stuff and stick to posix for more compatibility but for now this is what I could do

[bynect]

@fwsmit @zappolowski what do you think about this? I think it is a nice addition to check support for bsd. my only concern is the github ci compute times but maybe 2.30 minutes is not too much.

ps: I have no clue why the arch ci is failing but it seems unrelated

[Narrat]

ps: I have no clue why the arch ci is failing but it seems unrelated

Not that knowledgeable on that topic, but the glibc had an update that day. If the base archlinux docker was still containing the old glibc and the debug symbols pulled from debuginfod were the new ones... that sounds like something valgrind could trip over (valgrind not working was the reason for failing).
Should resolve if the docker image contains the new glibc package or the workflow should add commands (pacman -Syu --noconfirm) that should run on the arch distro.

Edit: reference for how it could be done: https://github.com/labwc/labwc/blob/master/.github/workflows/build.yml#L68

[bynect]

ps: I have no clue why the arch ci is failing but it seems unrelated

Not that knowledgeable on that topic, but the glibc had an update that day. If the base archlinux docker was still containing the old glibc and the debug symbols pulled from debuginfod were the new ones... that sounds like something valgrind could trip over (valgrind not working was the reason for failing). Should resolve if the docker image contains the new glibc package or the workflow should add commands (pacman -Syu --noconfirm) that should run on the arch distro.

Edit: reference for how it could be done: https://github.com/labwc/labwc/blob/master/.github/workflows/build.yml#L68

thanks for the tip! I updated our images and now it works again 👍🏻

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.31%. Comparing base (1827713) to head (3b5e925).

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1437      +/-   ##
==========================================
- Coverage   65.32%   65.31%   -0.01%     
==========================================
  Files          50       50              
  Lines        8763     8762       -1     
  Branches     1034     1034              
==========================================
- Hits         5724     5723       -1     
  Misses       3039     3039              

Flag	Coverage Δ
unittests	65.31% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[displaynameishere]

Looks good, I think the compute time being a bit higher is just freebsd being freebsd (unconfiged hypervisor, not tuned for vms like linux)

[bynect]

looking back there must be a smarter way to integrate this with our docker image repo

[fwsmit]

A freebsd runner sounds good, since dunst is packaged over there. It would also be a good idea to involve the dunst docker repository for consistency.

[bynect]

A freebsd runner sounds good, since dunst is packaged over there. It would also be a good idea to involve the dunst docker repository for consistency.

Ideally i would put it in the docker repo, however it makes some strong assumptions about the base image if i recall correctly. So maybe it is not the best suited for this kind of thing which requires to run qemu. If you have ideas on how to modify the docker repo accordingly I will do so

[fwsmit]

A freebsd runner sounds good, since dunst is packaged over there. It would also be a good idea to involve the dunst docker repository for consistency.

Ideally i would put it in the docker repo, however it makes some strong assumptions about the base image if i recall correctly. So maybe it is not the best suited for this kind of thing which requires to run qemu. If you have ideas on how to modify the docker repo accordingly I will do so

You could add the Ubuntu image with the necessary tools to the donker repo. By instelling as much as possible in advance you might save some time running the CI. Though I expect freebsd to still be slower

[fwsmit]

Why are you not using the freebsd docker image? https://hub.docker.com/u/freebsd

[bynect]

Why are you not using the freebsd docker image? https://hub.docker.com/u/freebsd

Good question 😆