Add NetBSD to CI targets?

[krytarowski]

It would be nice to add NetBSD to CI.

I propose to pick version NetBSD/amd64 8.0.

I'm not familiar myself with travis.

[AlexAltea]

Travis doesn't support NetBSD (or any other *BSD variant). Neither does any public CI-service I know of.

An extreme workaround would be to run NetBSD as a guest within an existent CI service that might support hardware-accelerated virtualization, and clone+build it there. But I don't know any such CI-service.

[krytarowski]

We can go with a workaround, it could be even in softemu as it's building of just relatively small sources of HAXM.

[krytarowski]

On the other hand.. there is another workaround we can test cross-compile from Linux. The only potentially obstacle would be nasm.

[krytarowski]

1. fetch all sets from http://cdn.netbsd.org/pub/NetBSD/NetBSD-8.0/source/sets/
2. unpack
3. ./build.sh -T /some/dir/with/tools -m amd64 tools
4. get haxm
5. cd haxm/platforms/netbsd
6. /some/dir/with/tools*/bin/nbmake-amd64

And hope that nasm will work out of the box.

[soul4soul]

An extreme workaround would be to run NetBSD as a guest within an existent CI service that might support hardware-accelerated virtualization, and clone+build it there. But I don't know any such CI-service.

This is what I do for a few projects. Albeit I didn't use any public CI-services and run the VM from a local machines but the concept is that same. It works well. The build time is a bit longer but it is better then no CI.

On the other hand.. there is another workaround we can test cross-compile from Linux. The only potentially obstacle would be nasm.

You wouldn't be able to run any tests by cross-compiling. Today tests only exist and run on Windows, so it is not an issue now. If HAXM GSOC is successfully there may be cross-platform tests.

[krytarowski]

An extreme workaround would be to run NetBSD as a guest within an existent CI service that might support hardware-accelerated virtualization, and clone+build it there. But I don't know any such CI-service.

This is what I do for a few projects. Albeit I didn't use any public CI-services and run the VM from a local machines but the concept is that same. It works well. The build time is a bit longer but it is better then no CI.

On the other hand.. there is another workaround we can test cross-compile from Linux. The only potentially obstacle would be nasm.

You wouldn't be able to run any tests by cross-compiling. Today tests only exist and run on Windows, so it is not an issue now. If HAXM GSOC is successfully there may be cross-platform tests.

We can do it incrementally. @AlexAltea are you interesting to setup it? I'm up to answer any questions, but basically all the steps are mentioned above with commands line-by-line.

[krytarowski]

NetBSD CI seems to be available, noted in ziglang/zig#1984

https://man.sr.ht/builds.sr.ht/compatibility.md#netbsd

[AlexAltea]

We can do it incrementally. @AlexAltea are you interesting to setup it?

Well, I think that the current build matrix of Linux/Windows/MacOS will probably catch any issues in haxm-core that may occur in any other platform. The only part that isn't tested is platforms/netbsd, but to be honest I personally don't have any motivation on working towards that (I don't use NetBSD).

That said, I don't see any reason to reject it either (but I'm not a maintainer here, just a contributor).

EDIT: Just to be clear, I don't oppose NetBSD CI targets. I just don't want to do the work myself. :-)

[krytarowski]

Well according to my experience code will just rot. Linux as a clone of BSD4.3 (from userland APIs point of view) is quite compatible to modern NetBSD.. but kernel internals are very different.

And myself I don't use Windows, Linux or MacOSX... so CI for them is needed from my point of view. Certainly analogously from people who still don't use NetBSD.

[raphaelning]

CI is always useful :-) If someone can make NetBSD build automation work (either cross-build using Travis CI or native build using another CI service) and submit a PR, I'm definitely willing to merge it.

[maronz]

FYI: I've just stumbled over the fact that the QEMU project appears to have recently added Cirrus CI for their FreeBSD compile testing.
I guess a starting point might be found here.

[AlexAltea]

Cirrus sounds like quite a good alternative, although it seems focused only on FreeBSD and not NetBSD.

Either way, if we manage to find a CI that supports NetBSD alongside Windows/Linux/MacOS, we probably should port the entire thing from Travis to the alternative (be it Cirrus or something else).

Disclaimer: It's just my personal taste: I'd simply prefer depending on a single CI, than on multiple CI services for each different host OS that we support.

[krytarowski]

Disclaimer: It's just my personal taste: I'd simply prefer depending on a single CI, than on multiple CI services for each different host OS that we support.

This almost makes unneeded blocker in my perception... but if it is really needed than:

https://github.com/billziss-gh/cgofuse uses single CI for all of them.

https://github.com/billziss-gh/pmci is a wrapper implementing modern BSD variations.

It claims that it uses Google Cloud service with Always Free limit.

I don't envision adding in future any general purpose OS other than the remaining modern BSDs, but if that will happen there will be certainly an option to extend pmci for this purpose.