Describe the enhancement
Support building the runner on FreeBSD
Additional information
I think FreeBSD has all the libraries that the runner needs. And while the dotnet-sdk isn't availble from Microsoft, there is already a package for it: lang/linux-dotnet-sdk . So it should be possible to build the runner on FreeBSD.
asomers
All 5 comments
We can't really do that for mainly 2 reasons.
- Supportability, without office support from dotnet core team, debugging any native dependency problem will be a nightmare.
- Legal, we (GitHub) might run into legal problem when we consume and redistribute 3rd party open source project.
But, we are totally fine with forking this repository and try yourselves, we are generally doing do on holding server/client compat.
Hope this can help. 馃槃
TingluoHuang
on 31 Mar 2020
Addition:
lang/linux-dotnet-sdk is based on a very old version. Considering the DotNet Core team is working on version 5 by now, I doubt anyone is willing to spend time debuging it, as @TingluoHuang explained.
Ornias1993
on 31 May 2020
We can add support if we do https://github.com/actions/runner/issues/243 or Dotnet 5 supports FreeBSD
TingluoHuang
on 6 Jun 2020
Sorry to bother you.
but I just created an action to make it possible to use FreeBSD in your workflow.
Neilpang
on 2 Oct 2020
I'd love to see FreeBSD support, but there's a long tail of other platforms. For Microsoft/snmalloc, we support Windows, macOS, Linux, OpenEnclave, and FreeBSD and have had external contributions for NetBSD, Haiku, OpenBSD, DragonflyBSD and Solaris. We support x86, ARM, MIPS, and RISC-V, (most in both 32- and 64-bit variants) and have CHERI versions in development for ARM, MIPS and RISC-V.
We would love to spin up CI for more of these, and can run a lot of them in Azure to provide self-hosted runners (at least for a weekly test run, if not on every PR), but porting .NET to all of them and having supported releases is a phenomenal amount of work, particularly over the next couple of years as we grow the amount of CI that we want to run on experimental hardware.
It would probably be more valuable to the community to have the protocol that the runners need to speak documented so that third-party contributors can implement something for operating systems that don't have first-party support. The only thing that I need a runner to do for our CI to work is install some packages, download the code, and run a shell script, then report the results. A minimal C++ implementation that I can compile to a statically-linked binary to provide this minimal environment would be ideal for our purposes.
The fact that the only way of getting FreeBSD / OpenBSD / Solaris CI on GitHub actions currently is to spin up a Mac worker and run the desired OS in a VM is quite sad, especially since the initial launch announcement said that other operating systems would be supported.
davidchisnall
on 6 Nov 2020
Related issues
ScottOFX
路
3Comments
ericsciple
路
7Comments
airtower-luna
路
5Comments
rkuhlercadent
路
7Comments
joequincy
路
4Comments
Most helpful comment
I'd love to see FreeBSD support, but there's a long tail of other platforms. For Microsoft/snmalloc, we support Windows, macOS, Linux, OpenEnclave, and FreeBSD and have had external contributions for NetBSD, Haiku, OpenBSD, DragonflyBSD and Solaris. We support x86, ARM, MIPS, and RISC-V, (most in both 32- and 64-bit variants) and have CHERI versions in development for ARM, MIPS and RISC-V.
We would love to spin up CI for more of these, and can run a lot of them in Azure to provide self-hosted runners (at least for a weekly test run, if not on every PR), but porting .NET to all of them and having supported releases is a phenomenal amount of work, particularly over the next couple of years as we grow the amount of CI that we want to run on experimental hardware.
It would probably be more valuable to the community to have the protocol that the runners need to speak documented so that third-party contributors can implement something for operating systems that don't have first-party support. The only thing that I need a runner to do for our CI to work is install some packages, download the code, and run a shell script, then report the results. A minimal C++ implementation that I can compile to a statically-linked binary to provide this minimal environment would be ideal for our purposes.
The fact that the only way of getting FreeBSD / OpenBSD / Solaris CI on GitHub actions currently is to spin up a Mac worker and run the desired OS in a VM is quite sad, especially since the initial launch announcement said that other operating systems would be supported.