search

fleetdm / fleet

Open-source platform for IT, security, and infrastructure teams. (Linux, macOS, Chrome, Windows, cloud, data center)
https://fleetdm.com
Other
2.98k stars 413 forks source link

Explicit `amd64` and `arm64` Windows targets #19960

Open dantecatalfamo opened 3 months ago

dantecatalfamo commented 3 months ago

The way Windows support currently works in development environments causes confusion and subtle issues.

Problem

Windows ARM inside a VM is the easiest way to test Windows support locally, as x86 VM emulation on Apple Silicon is prohibitively slow. Current (unofficial) Windows ARM support is implicit through windows emulating x86 for programs compiled for that target. This works well in most cases but leads to many subtle issues in development.

When a developer is working on fleet and compiles a client with a local TUF server, it compiles using the native architecture. For most of the developers on this project, that is arm64. Since there's only one WIndows platform on the TUF server, when the developer compiles the installer or updates the TUF server, it will create ARM binaries that don't work on any x86 machine, meaning any actual hardware machine or x86 VM will not be able to run it.

This workflow of modifying the compilation and TUF targets is undocumented and has led to issues in QA and developer testing.

Potential solutions

  1. Explicitly set the target arch to amd64 when targeting Windows. This could possible introduce emulation-related bugs when testing on local machines. We will also need to introduce an arm64 platform some time in the future when Windows-on-ARM hits the mainstream.
  2. Add a new windows-arm64 TUF platform and compilation target
noahtalerman commented 3 months ago

Thanks @dantecatalfamo!

Unless I'm missing something, it sounds like this change benefits mostly Fleet contributors and less so Fleet users/contibutor.

So, I'm removing this one from ~feature fest and into the engineering initiated prioritization process.

cc @lukeheath

dantecatalfamo commented 3 months ago

Sounds good, I just left the default tags when I created the issue. This is mostly a developer experience issue, but I've seen several people trip over it and it's not explained