Skip to content

Run the tests on Windows CI - #3065

Open
julianoes wants to merge 5 commits into
mainfrom
pr-windows-system-tests
Open

Run the tests on Windows CI#3065
julianoes wants to merge 5 commits into
mainfrom
pr-windows-system-tests

Conversation

@julianoes

Copy link
Copy Markdown
Collaborator

Windows is the only platform where we build the unit and system tests on every PR but never run them. This turns them on, for Intel and arm.

  • x64 and x86: they build natively on the windows-2025 runner, so the existing library build jobs just get a unit tests and a system tests step (with install\bin on PATH for mavsdk.dll).
  • arm64: the library build is cross-compiled and can't run on that runner, so there's a separate Windows arm64 tests job on the native windows-11-arm runner which builds and tests only. The release artifacts keep coming from the existing cross build, untouched.
  • The FTP and mission tests wrote to a hardcoded /tmp/... path — that's what the TODO: make this compatible for Windows using GetTempPath2 comments were about. They now go through std::filesystem::temp_directory_path().

Let's see what CI says. If some tests turn out flaky on Windows I'd rather find out here than after merging.

The FTP and mission tests wrote to a hardcoded /tmp path, which is why they
carried a TODO about Windows. std::filesystem::temp_directory_path() gives us
the right place on every platform, so use that.
Windows was the only platform where we built the unit and system tests
without ever running them.

The x64 and x86 builds run natively on the runner, so they just get the two
test steps. The arm64 library build is cross-compiled and can't run there, so
it gets a separate job on a native arm64 runner which builds and tests only.
Windows resolves an empty hostname to the wildcard address, because we ask
getaddrinfo with AI_PASSIVE, while Linux and macOS return an error. The unit
test expects it to fail, so reject it before we ask at all.
@julianoes
julianoes force-pushed the pr-windows-system-tests branch from bf7fd1b to da25395 Compare September 2, 2026 09:16
Windows reports an ICMP port unreachable, caused by us sending to a remote
which has gone away, as an error on the next receive. We treated any error as
the end of the connection and stopped receiving, so a UDP link never came back
once the other side had been away.

Tell Windows to stop reporting those errors, and treat the ones about a single
datagram as non-fatal so we keep listening either way.
One thread per subscription needs more address space for the stacks than a
32-bit process has, which is why the test died on Windows x86 without any
output.

Do the same number of subscriptions from a sensible number of threads, which
keeps the contention the test is after and takes 120 ms instead of seconds.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant