Add BSD to CI.

[ncruces]

This adds FreeBSD, OpenBSD, and NetBSD to CI.

The weird regex (imports|sysfs) skips the following packages:

• internal/sysfs
• experimental/sysfs
• imports/assemblyscript
• imports/assemblyscript/example
• imports/emscripten
• imports/wasi_snapshot_preview1
• imports/wasi_snapshot_preview1/example

Mostly, sysfs and WASI need further work, even on FreeBSD.

I propose we merge this as is, if for no other reason, to ensure no regressions. Later, we can figure out what needs to be fixed/skipped. Most of the issues are WASI details/intricacies.

Instead of using the regex, we should probably skip specific WASI tests. Either based on GOOS, or some supports_X (test?) flags. A bunch of tests fail because of non-portable stat fields; others because of reduced file time resolution; etc.

Users of these OSes that interested in fixing the actual behaviour are encouraged to do so, then whitelist tests.

Also: the fact wazero works and is used in these OSes with little to no complaints suggests these details don't matter that much in actual usage. WASI is complicated, our implementation of it is already very complex. It's also a preview.

[mathetake]

• internal/integration_test/engine
• internal/integration_test/fuzzcases

I think we need these two to pass to say the core is working - what's the failing tests in there?

[ncruces]

A few more notes.

This uses cross-platform-actions/action which in my experience is the best option for these OSes.

I'm planing a follow up PR that uses vmactions for other OSes, but that is a bit slower than these, and adds a bit more infrastructure (we need a templated custom action for a matrix run). We can do DragonFly BSD, illumos and Solaris that way, though.

We can also use cross-platform-actions/action to test arm64. It would be slower (CPU emulation), which compounds with the interpreter for additional overhead.

I am not testing multiple Go versions, nor am I installing a specific Go version; instead, I use the preinstalled GitHub Go version. Both these actions start a VM and rsync stuff into the VM. They don't know what exactly to copy, and they aren't very configurable here. If we install Go, they end up copying the entire local Linux Go installation into the VM for no reason.

[ncruces]

• internal/integration_test/engine
• internal/integration_test/fuzzcases

I think we need these two to pass to say the core is working - what's the failing tests in there?

fuzzcases repeatedly crashes OpenBSD with an out of memory: https://github.com/ncruces/wazero/actions/runs/11840657747/job/32995009277

engine does the same to all 3 OSes (two of the VMs simply die with no error message):
https://github.com/ncruces/wazero/actions/runs/11840579279/job/32994741104

I can try to isolate the test cases. If you have any hints/suspicions, it'd be helpful.

[mathetake]

ok then we might need to try -short as some cases use incredible amount of memory:

• wazero/internal/integration_test/fuzzcases/fuzzcases_test.go

  Lines 330 to 334 in dc08732

  	if testing.Short() {
  	// Note: this case uses large memory space, so can be slow like 1 to 2 seconds even without -race.
  	// The reason is that this test requires roughly 2GB of in-Wasm memory.
  	t.SkipNow()
  	}

• wazero/internal/integration_test/engine/memleak_test.go

  Line 18 in dc08732

  t.Skip("skipping memory leak test in short mode.")

[ncruces]

Yeah, that fixes it!

(sorry for the additional PR, it was meant to be on my fork, to run CI)

[ncruces]

Updated the initial comment, for more visibility of the current state of play.

I'd like to highlight this:

Users of these OSes that interested in fixing the actual WASI behaviour are encouraged to do so, then whitelist tests.

They can run the tests locally with make test and fix things much more easily that we can.

[mathetake]

Can you reflect the state of OS support in https://github.com/tetratelabs/wazero?tab=readme-ov-file#platform ?