-
Notifications
You must be signed in to change notification settings - Fork 243
Add Solaris and FreeBSD to our CI #620
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
4dcb4ac to
784d017
Compare
784d017 to
2271022
Compare
carenas
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a more convoluted version of this in the "solaris" branch in my fork that I didn't propose because it is too inefficient CPU wise, and we don't really know if Microsoft might eventually tighten the screws in their "free" plan.
This is IMHO a good place were a corporate sponsor and alternative CI providers might help, but will likely require more infrastructure work (including maybe setting a "non profit" or piggybacking on the ones that are around to help projects like us)
.github/workflows/build.yml
Outdated
| freebsd: | ||
| name: FreeBSD | ||
| runs-on: ubuntu-latest | ||
| if: github.event_name != "pull_request" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
presume trying to save some CPU time?
FWIW we could also use cirrus CI which provides native FreeBSD runners (hosted in google cloud) instead
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. But I don't see a compelling need to switch, for now.
We'd still need a VM for Solaris.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cirrusci provides their own VMs which perform better than GitHub's
.github/workflows/build.yml
Outdated
| run: | | ||
| set -e | ||
| ./configure --enable-jit --enable-pcre2-16 --enable-pcre2-32 | ||
| gmake -j3 CPPFLAGS='-Wall -Wextra -Werror' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why did you force gmake?, their native make should work too IMHO, and it would be nice if we introduce some GNUism by mistake
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It failed with Solaris make, so I just used gmake. I didn't consider it important what make system works - as long as the code compiles & runs, we're fine.
But if you prefer using Solaris make, I'll try and fix it.
I've also decided to have an attempt at using Solaris cc rather than GCC.
81ac449 to
9d75c65
Compare
|
OK, ready for review again. It's now using Oracle's SunStudio compiler (Sun |
9d75c65 to
877c52a
Compare
|
@diizzyy Daniel, just to let you know, I'm adding a FreeBSD runner to our master CI. |
|
@NWilson |
|
I guess we could. However, we already have plenty of CI jobs using CMake, so we should be OK on that system. For the rarer unix platforms, it's simpler just to have one CI job that tests the lowest-common-denominator for the build; hence why I just tested the autotools build. |
These are only run after a PR is merged, not every time you push to a PR.
They use a third-party GitHub Action that starts up a VM using Qemu.
The Solaris one is cheating a little - I'm using GCC rather than Oracle Developer Studio's
cccompiler, because that's a real pain to install. On the other hand, most people probably use GCC on Solaris now anyway, so maybe it is a fair test of whether our Solaris support is OK.