feat: Add windows binary artifact in the release

[TalaatHarb]

What problem are you trying to solve?

Just to increase adoption, add windows binary artifact as part of the release pipeline

Proposed solution

modifying the release pipeline to be a matrix release for both windows and linux

Alternatives considered

No response

Additional context

No response

[TalaatHarb]

I'm thinking something like the following:

• Add a Windows CI job to .github/workflows/ci.yaml, likely windows-latest, running:
  • cargo fmt --all -- --check
  • cargo clippy --locked --all-targets -- -D warnings
  • cargo test --locked
• Add a native Windows release matrix entry in .github/workflows/release.yaml:
  • runner: windows-latest
  • target: x86_64-pc-windows-msvc
  • Build and verify target/.../release/sofka.exe with sofka.exe --version.
  • Package the Windows binary as a ZIP rather than .tar.gz, then include it in checksums, provenance attestation, and GitHub Release assets.
  • Keep the existing Linux/macOS packaging and compatibility checks unchanged.

[nklmilojevic]

Thanks for opening the issue. It is a bit tricky to support Windows, especially with recent sofka-plugins, that would mean we would also have to add a pipeline there to create plugins for Windows as well. While it is certainly doable, it adds considerable maintenance burden. I'll for sure do this in the future and I will keep this issue opened - but right now the only supported way for Windows is through WSL which should work totally fine.

[TalaatHarb]

thank you, for now I will build my own windows binaries then.

[nklmilojevic]

@TalaatHarb please report the bugs that you find that are related to Windows because it will also help me plan for support better!

[vyrti]

I dont think it will be maintenance burden, plugins are in rust and will work on windows for sure
(if app called from plugin are supported on win)
also its possible just to gate that plugin system feature on windows and ship without it
the only problem that not that much people have windows to check builds before release
so QA will be low
so possible to provide unofficial untested builds I believe
rust code works everywhere, x64/arm windows, linux, mac, freebsd

many ppl in enterprises/corpos are forced to use windows on work, so will be handy for sure

[nklmilojevic]

Yes, but it is not just adding the release process, it is many other things, how tests are written, how plugins are written, etc. I will for sure support this, but it is not just a CI process change.

[vyrti]

yeap, I did not offered this as I do have windows now, but this is temporary
I think this can be postponed to moment when we have permanent maintainer with windows

but i think it still worth to gate plugin system and at least add windows build support in code, not in CI

@nklmilojevic
btw seems that WASMi via Host Functions makes possible to create one unified artifact for all platforms and architectures
like arm64/x64 windows/mac/linux
but it will require WASMi in sofka, and limit plugin language to Rust only
this is superpower of rust btw.
will add 2Mb to release binary (tested)
Wasmi reached 1.0 in dec 2025, and now its 2.0 after 8 years of dev. previosly wasm used to add 25Mb to binary. not anymore
I can run a research and confirm if it works or not, if you are interested

its technically possible to write all plugins in python as well, they will work everywhere, but python will become a dep
(does not look as good idea :P)

[nklmilojevic]

Yes please, run a research, keep in mind we also have a nix release process.

And 100%, we only want Rust as Sofka language. External plugins (not in sofka-plugins registry, but in their own repos) can be in different languages, but sofka and sofka-plugins will be Rust only.

But also, I'd like to keep out of external dependencies for release so lets see what experiment shows :)

[vyrti]

research started
(nix is supported by wasmi as well)

[vyrti]

@nklmilojevic 100% success as expected
popeye and chaos plugins tested
https://wasmi-labs.github.io/blog/posts/wasmi-v2.0/

speed: 1-2ms slower on small tasks (50 pods)
but if tasks involve 5000+ pods its 11x times slower (300ms vs 30ms)
plugins usually does not interact with that amount, so maybe can be optimized
if app is called then app is doing same work it did with native plugin

but it does not have startup time, etc.
I dont know how firestarter or aws lambda works and why they are so extremely slow,
but this wasmi is instant 0.19ms and aws lambda c++ is 19.84ms https://maxday.github.io/lambda-perf/
plugin size: 3 times smaller (no adapter in each new plugin), either packed or unpacked

compatibility: 100%

exactly same wasmi module from mac m1 arm tested on (hash compared on each system):
windows 11 x86 AMD
ubuntu 26 x86 Intel
mac m1 ARM
not tested on nix, but if works on x86 while was compiled on arm and works on arm, and works in ubuntu,
basically will be tested if u decide to switch (during PR preparation)
https://mynixos.com/nixpkgs/package/wasmi

sofka binary grew by 1.4Mb

that was my initial idea about plugins when I was offering plugin system, but was created according to specs in sofka-plugins repo
there are disadvantages in wasmi compared to native rust code indeed, like
Wasmi 2.0 officially provides WASI Preview 1, but considering wasmi development speed in last 2 years, i think that most of the ceilings where we can hit will be sorted in next 1-2years
and sofka life will be like 10-15y (at least)

Zellij migrated to wasmi from wasm in 2026 (35k stars on github)
https://github.com/wasmi-labs/wasmi#used-by

my recommendation: worth serious consideration and time spend on you own research

P.S 1000 files vs 6000 files for all platforms when there will be tons of plugins is a good point as well

raw code if interested:
vyrti/sofka spike/popeye-wasmi-in-sofka
vyrti/sofka-plugins spike/chaos-kill-wasmi

[nklmilojevic]

Solved and currently releasing in https://github.com/nklmilojevic/sofka/releases/tag/v0.28.0