search

google / cpu_features

A cross platform C99 library to get cpu features at runtime.
Apache License 2.0
2.44k stars 258 forks source link

FreeBSD CI support #362

Open toor1245 opened 2 weeks ago

toor1245 commented 2 weeks ago

Checked another solutions to support FreeBSD CI:

freebsd-vm:

It looks like this solution supports only amd64 architecture https://github.com/vmactions/freebsd-builder/blob/main/conf/freebsd-14.1.conf#L3

However, in builder script there is VM_ARCH https://github.com/vmactions/freebsd-builder/blob/f799d8fb9b84977ec8fa020178262de39eaa4b83/build.sh#L35

and upcoming features:

Maybe it’s possible manually configure the architecture somehow, but at the moment it looks like a hardcoded architecture amd64

cross-platform-actions:

This action supports FreeBSD amd64 and arm64 architectures and we support these architectures for FreeBSD: https://github.com/cross-platform-actions/action?tab=readme-ov-file#freebsd-freebsd

I used this solution, proof of success:

It worth noting that googletest doesn't work with bazel in FreeBSD, so we use only cmake in CI: https://github.com/google/cpu_features/pull/295#issuecomment-1722500335

We can try to add only build for bazel.

toor1245 commented 1 week ago

@gchatelet, @Mizux, could you please review PR?

Mizux commented 1 week ago

Sorry for the delay, still need to think about it... Please see below my few pro and cons, i.e. my current thought about this PR:

On the bright side: a) having two jobs working is better than nothing (or our previous broken one) -> Many thanks for taking the time to fix our BSD CI support !

b) leveraging github actions reduce our technical debt and reducing scripts length...

On the cons side: c) Using actions means the migration/fork to another CVS (e.g. gitlab) make this more difficult, usually I prefer so stick with the bare minimum actions (i.e. checkout) and only from github (i.e. kind of "official" actions) then having everything in the .yml directly or inside a versioned script. i.e. minimize the vendor lock-in.

d) Using actions means we can't easily locally test or we need to maintain a second scripts with overlap to the github action... -> I prefer to have a script to run locally and the CI is just a dumb runner which can run it for me. -> I think, github actions often hide the two bash script lines needed to run it locally. -> I'm biased with my Makefile + Docker/Vagrant CI setup ;)

e) vmactions/freebsd-builder seems brittle and may allow some supply chain attack (ed very low risk since we don't deploy or share/use any token). Actually, my main concern is more the test of time, AFAIK only "neil" seems to be the maintainer of this tooling and I don't like this kind of change where both repos need to be in sync...: https://github.com/vmactions/freebsd-builder/commit/3db1a35a5f84167fb47912440ba4e4c893798d43 https://github.com/vmactions/vbox/commits/main/ (only 2 stars -> not battle tested and brittle ?)

ps: Still want to explore vagrant on ubuntu-latest path too (in this case we could keep our ci/Makefile/Vagrant stuff just change the runner base image and do few setup)! see: https://github.com/magma/magma/pull/15381/files#diff-6cea9de55c2b40b7e046ce2f3b096f80f3f7018ac52fa6e55ba11a6ffce4c6f7R105-R108

As usual feel free to comment any points and change my mind, I'm still thinking about it ! One scenario could be to accept this PR as "temporary" solution until we have a new PR challenging it ;)