Tracking issue: expand CI testing

[Thomasdezeeuw]

CI support, following the same tiers as rust (https://doc.rust-lang.org/nightly/rustc/platform-support.html).

Tier 1

Tests must pass.

• Linux: tested.
• Windows: tested.
• macOS: tested.

Tier 2

Must build.

• Android: check only.
• FreeBSD: check only.
• Fuchsia: check only.
• NetBSD: check only.
• Redox: check using Rust nightly only, stable is tracked here: Fix building on Redox on Rust stable #181.
• Solaris: check only.
• iOS: check only.
• illumos: check only.

Tier 3

Best effort.

• Haiku
• Hermit
• OpenBSD
• VxWorks
• DragonFly BSD

---

Old description:

Currently only Linux, macOS and Windows are tested on the CI but we support (to some degree) many more OSes. We should add more of these OSes to the CI, at least running cargo check. For (Rust) tier 1 architecture/OS combos this should be easy, but for other tiers rustup might not be supported.

[KodrAus]

cc @rust-lang/infra I think we have a few repos in rust-lang with fairly extensive CI suites. Can we think of any examples that we could use to bootstrap some broader CI here? I'm thinking particularly of iOS...

[Thomasdezeeuw]

@KodrAus, @rust-lang/infra a little update: tier 2 targets are now all cargo checked, but if it's possible to actually run the tests somehow I would prefer that.

[KodrAus]

@Thomasdezeeuw I'm guessing it's more the OS than the architecture that you're interested in for the tier 2 targets?

It looks like we might be able to use MacOS workers in GitHub Actions to run some of the BSDs. Alternatively, Travis CI does seem to support FreeBSD (although I can't find any docs on it), which we do still use in some repos here in rust-lang (specifically stdarch and stdsimd).

[Thomasdezeeuw]

@Thomasdezeeuw I'm guessing it's more the OS than the architecture that you're interested in for the tier 2 targets?

Yes let's start with the OS. I think if we can run tests on all supported OSs, on any architecture, we can ensure the functionally works. Than cargo check would be enough for different architectures just to make the we got the libc definitions and functions right.

It looks like we might be able to use MacOS workers in GitHub Actions to run some of the BSDs. Alternatively, Travis CI does seem to support FreeBSD (although I can't find any docs on it), which we do still use in some repos here in rust-lang (specifically stdarch and stdsimd).

There is also https://cirrus-ci.org/ for FreeBSD, e.g. Mio uses the following file: https://github.com/tokio-rs/mio/blob/04050dbd87d7b79c33168c6a972a8bb35cf510f8/.cirrus.yml.

[Thomasdezeeuw]

Don't think there is much left to do here, so closing.

[jkelleyrtp]

I believe WASI can be supported since their lib-c exposes sockets. I'd be interested in adding it.

[Thomasdezeeuw]

Sounds good @jkelleyrtp. Although last I check (I think version 9/10) WASI didn't allow for the creation of sockets, however that could have changed. In either case the various socket options could still be useful.

[LetsMelon]

I believe WASI can be supported since their lib-c exposes sockets. I'd be interested in adding it.

I would be interested in giving it a try. However, after looking a bit through the codebase, I feel that it might be somewhat complicated and not that easy at the moment.

Sounds good @jkelleyrtp. Although last I check (I think version 9/10) WASI didn't allow for the creation of sockets, however that could have changed. In either case the various socket options could still be useful.

I think that's still true, but there is an open and active proposal to add the functionality to create sockets (https://github.com/WebAssembly/wasi-sockets/blob/f2ffc745086ec7ab168f1244f2b3ef0342bf9ddc/wit/tcp-create-socket.wit#L26 and https://github.com/WebAssembly/wasi-sockets/blob/f2ffc745086ec7ab168f1244f2b3ef0342bf9ddc/wit/udp-create-socket.wit#L26) which is currently in 'Phase 3 - Implementation Phase (CG + WG)'. The proposal has been already introduced in WASI Preview 2 which the newly announced target wasm32-wasip2 follows. In the introduction blog post under Conclusion it's encouraged to use cargo-component until the newly created target achieves tier-2. In cargo-component I found a reply from @sunfishcode to an issue that 'work on supporting that (Preview 2, sockets) in libc is underway'.

At the time of writing, WASIX has support via sock_open() to create sockets.

---

I'm just a random user who stumbled upon this problem: socket2 cannot be built with the target wasm32-wasi. I'm not a wasm/wasi wizard, so please correct me if I have made an error or overlooked something.

[Thomasdezeeuw]

Let's have the discussion in the other thread (#268 (comment)).