Repository navigation
Should non-CLI components build or run on non-Linux platform #2517
Description
We currently have a loose notion of what platform the system components can build and run on:
- We heavily depend on Linux mechanisms such as namespaces that are heavily OS-dependent
- We don't have explicit abstractions in the code to support this.
Suggestion (for now):
- Support only Linux-OS platforms in the server-side components. e.g. atelet, atenet, etc. There are some Linux build tags in the go-files right now, but we won't be reorganizing the code to wholesale support other platforms for these components.
- CLI may be a special case -- this one will need to be cross-platform. To that end, we need to make sure there 1) default build skips the server-side components and/or 2) offer a way to build only the CLI etc that should be x-platform.
Activity
BenTheElder commentedon Oct 13, 2026
We should keep that, because being able to unit test packages on other platforms (macOS) is valuble.
We should explicitly build-tag things linux to indicate those things that only support linux. That includes the binary mains for these components.
CLI must be cross-platform and the default build should not compile anything else cross-platform.
abhisheksharma2411 commentedon Oct 14, 2026
Some measured data on the current state, since I ran into this from the outside.
CI only ever builds one target -
GOOS=linux GOARCH=arm64inpr-workflow.yaml:60- and there are no macOS or Windows runners. So nothing checks any other platform.But right now at
5df6990athe tree is in better shape than that suggests:The part I think argues your case: it was broken a day ago and healed without anyone noticing. Building on darwin at
fd7a9cdefailed withand the same package builds clean at
5df6990a. I only know that because I happened to build it on both. So the "loose notion" is loose enough to regress and recover silently.If it'd help, I'm happy to send a small PR adding a cross-compile step for the CLI (darwin/arm64, darwin/amd64, windows/amd64) so point 2 in your suggestion is actually enforced rather than true by luck. That's a compile-only check, so it costs a job and no runners. I'd leave the server-side components out, matching what you wrote about not reorganising them.
BenTheElder commentedon Oct 14, 2026
No, we also e2e test everything on Linux/amd64 ...
With no impact to the CLI.
I'd prefer to make sure this is aligned to the release builds work. Cc Steven Shriver (@stshrive)
I'm not sure it's worth the cost to actually compile for these.
We don't need to run the tests / build the other packages for Mac but we should aim to have them compile or be explicitly Linux tagged. Kubernetes has tooling for a cheap typecheck.