Workflow: FreeBSD Current Builds Runner

[bedwardly-down]

For FreeBSD, there are two main branches that would need to be tested against: Current (13.3 and 14.1) and 2nd Tier (13.2 and 14.0). 2nd Tier is the equivalent of Ubuntu LTS and Current is the stable bleeding edge branch. None are binary backwards compatible but all get released in pairs around the same time, so there would be shifting every few months (based on what the runner supports), but this is ready unless you have issues with it or there are bugs.

Because FreeBSD runs as a vm inside of an Ubuntu vm, performance and compilation speed will take a hit, but the sdk builds should be fully testable by others on 14.1 64-bit. It’s also going to be mostly running in vm instead of using external runners for things like git checkout, ninja + cmake, etc. Until a builder is officially supported, these will be mostly ran directly in the vm.

[bedwardly-down]

That’s an issue I’ve been running into. ui_uiedit.h randomly fails to moc or gets missed when running on anything above a single core locally or with the runner. Not sure why it’s happening yet but know it’s exclusive to that header. I have most of tomorrow off so one possible solution is setting up caching, doing a single full build and keeping all FreeBSD builds locked to a single core until other platforms are tested. Incremental builds would be faster and it shouldn't be too difficult to set up for all supported targets.

This is going towards #783

I want to keep testing to the latest 4 stable FreeBSD releases but can just build against 2nd Tier since they're more stable and expected to be supported longer if that number is too much. Having a bigger surface to test on would hopefully increase the amount of users of your engine and lead to much of your backlog in terms of features getting resolved. But, it would also increase overall build times and some versions of FreeBSD may have failures while everything else and other version pass. I don't want to drastically increase your workload and will gladly work on the bugs that come up but may not be able to resolve them on my own (depending on what they are).

[bedwardly-down]

Waiting on everything to build properly. If CCache works as intended and you approve of the build system change here (mainly as a solution to a quirk and also as a possible solution to a CMake issue that could be a problem for the other platforms), this is ready to merge.

Also, further clarification about the 4 stable releases to test against statement above:

FreeBSD 14.1 and 14.0 and 13.3 and 13.2 are all essentially different operating system releases built on the same kernel base based on version number. The version 14 kernel is essentially the v6 branch of the Linux kernel while version 13 is the v5 branch instead. It's not an exact direct correlation. Another way to look at it is the current Version 14 and 13 releases are Windows 11 built on different kernel bases while the previous releases are Windows 10 with the same logic. When version 15 releases and the FreeBSD runner gets updated to support it, then version 13.2 will become dropped in this setup. The platform's release structure takes a bit to get used to but I only want to test against the latest 4 stable releases because those are what's going to be actively supported upstream.

[bedwardly-down]

I was attempting to be clever by setting up ccache in the top level CMake file but it's ignoring that, so it's going to be scripted directly in the run part of the workflow script. Might still be able to set them in that file for the other platforms since they're not running in an embedded vm of a vm. At least right now, consistent release SDK builds are coming.

The Github docs say the free cache is 500 MB, which is perfect because the full build cache (see the end of the Build log; I have it printing the current stats of the ccache directory, environment variables, etc) is just under 400 MB, so, if all else fails, whatever the last package built was, that would essentially swap out the cache and be the fastest build next time meaning that at least one of the CMake builds will be done early freeing resources for the others.

I'm using this as a reference to get the CCache stuff setup, btw: https://cristianadam.eu/20200113/speeding-up-c-plus-plus-github-actions-using-ccache/ . It's been very helpful

[bedwardly-down]

Partially worked. The environment variables are now being used. Hopefully, this next iteration will get caching working as intended. Almost there. 😹

[bedwardly-down]

Not finished yet but now have caching initially working. They’re mostly empty due to what are hopefully permissions quirks with the freebsd runner. That’s definitely my wheel house. 🤘

[bedwardly-down]

Won't have time to work on this this morning (running late for my job) but I've pulled in latest master and merged it and my current work into a new branch. There's some slight breakage with the QML updates but nothing too major on that front. If the Qt6 upgrade fixes the Moc issue (not fully sure how it works compared to Qt5's), setting up caching wouldn't be a fix but instead just a nice to have that could still be useful in the long run. Because I've started integrating the freebsd-vm runner code into the build system, once some hard coded parts are ironed out, I'll have the means to still test against different stable releases without worrying about taxing the CI build system too much for the other platforms.

[bedwardly-down]

Up early working on this some. I have around an hour at most but the qml breakages are removed. I've also moved to Ninja from gmake for local builds. So far, the ui_uiedit.h moc bug hasn't shown up yet but will. 😿

[bedwardly-down]

Closing this due to a merge making it obsolete.