Add support for --no-container to run windows/macos

[chenrui333]

Thanks for creating this wonderful tool. It would be nice to have MacOS also supported as well.

[cplee]

All steps for act run in a docker container...not sure how to accomplish that with MacOS runner. Would you want it to NOT use a container and just run the commands directly on the mac that act is running on?

[fwilhe]

Kinda related: Sometime I think you really don't want to run stuff in containers, for example when act is invoked in a container itself which contains the required software already. Not sure if this is in scope, but it would be kind of nice if it had a --no-container flag which would do what it does now, except for using the locally installed tools..

How feasible would this be?

[cplee]

I like the idea @fwilhe - would like to see a flag --no-container that runs all the steps directly on your local workstation, and assumes the right tools are installed. This would enable both windows and macos environments.

[cplee]

@albertofem - this looks really promising! What do you think about also supporting --no-container to force the platform to be host?

[fwilhe]

In my experience it is a viable workaround for failing setup actions to build a docker image that has everything your build needs. Provides you the same experience locally and in actions if you run your workflow in the image.

[jcansdale]

@fwilhe I did wonder about doing that. It's good to hear that it works well in practice!

Since you can optionally specify an image to use with Codespaces, this could be a good opportunity to sync-up build and development environments. 🤔

[albertofem]

@cplee Yes, I think the flag makes more sense for the general case rather than assuming non-supported hosts. I'm gonna rework my brach and come back as soon as I have something ready for review.

[jonioni]

Still care +1. This may also solve certain scenarios as in #119 and #107 without having to download a 20GB image.

[catthehacker]

Are the plans to add support for windows & mac still active?

The issue is not closed so...

[FranklinYu]

You all are clearly quite ahead of me but one more thought I'd like to add, perhaps adding support for qemu might be interesting. It would likely be a lot more work, but it would pave the way to for full macOS and Windows support.

macOS on QEMU on KVM is against Apple EULA (End User License Agreement), FYI. This at least mean that support will be limited, and bug will be expected.

Not sure about Windows; perhaps they allow you to run Windows VM without a license?

[jacob-carlborg]

macOS on QEMU on KVM is against Apple EULA

You're allowed to virtualize macOS on Apple hardware.

[FranklinYu]

That's too much work for such little project especially since what you linked, those projects are not written in Go so it will be hard to make them work together.

How about https://github.com/penberg/go-osxhv? Direct cgo binding of Hypervisor Framework (i.e. the backend of xhyve).

[fugkco]

macOS on QEMU on KVM is against Apple EULA (End User License Agreement), FYI. This at least mean that support will be limited, and bug will be expected.

Not sure about Windows; perhaps they allow you to run Windows VM without a license?

It's not up to this project to figure out licensing anyway. It's up to the individual user of it to ensure they don't run Windows and macOS against Microsoft/Apple ToS.

[fugkco]

qemu has absolutely terrible performance and breaks easily

I guess when I said qemu I meant qemu-kvm which should provide near native speeds. I can't say much about it breaking easily though as I've always used it through frontends.

[jacob-carlborg]

How about https://github.com/penberg/go-osxhv? Direct cgo binding of Hypervisor Framework (i.e. the backend of xhyve).

You would need to reimplement a hypervisor, basically what Xhyve and QEMU are already doing. Probably a huge amount of work.

[davetapley]

Just to throw it out there: If ⬇️ ever gets done then that might be another way to support Windows runners?

• Support to deploy Windows containers to ACI using the Docker CLI docker/roadmap#138

[Lewiscowles1986]

Perhaps a point others have considered. But why would running locally be the default for no-container, versus something like specifying an IP to a machine; which could just be a vagrant to use a VM to run in? I Feel like this must be what GitHub is doing anyway if they are providing a clean-room on every run. Just build a box (nee golden image); provide ssh to connect to and pull files from, run some commands. When done, run a command to "clean" the box (in case of a VM, stop it, delete it, spin up another for next-time command runs).

[catthehacker]

But why would running locally be the default for no-container, versus something like specifying an IP to a machine; which could just be a vagrant to use a VM to run in?

Because you can just use ssh and then act inside it. Sure it's less convenient, but re-implementing remote execution or implementing 3rd party lib adds a maintainenace burden and requires manpower.

[Lewiscowles1986]

I'm fairly certain the request is because this won't run windows or macosx regardless of them being in a vm, but okay. Thanks for quick response.

[lotyp]

Maybe this can help ? https://github.com/sickcodes/Docker-OSX

Run Mac OS X in Docker with near-native performance! X11 Forwarding! iMessage security research! iPhone USB working! > macOS in a Docker container!

This project is built on top of upstream project: https://github.com/kholia/OSX-KVM

[catthehacker]

Maybe this can help ? sickcodes/Docker-OSX

Run Mac OS X in Docker with near-native performance! X11 Forwarding! iMessage security research! iPhone USB working! > macOS in a Docker container!

This project is built on top of upstream project: kholia/OSX-KVM

Please read before posting. I already mentioned it and it doesn't solve the issue as it runs Docker inside Linux VM inside macOS VM as Docker container.

[lotyp]

Maybe this can help ? sickcodes/Docker-OSX

Run Mac OS X in Docker with near-native performance! X11 Forwarding! iMessage security research! iPhone USB working! > macOS in a Docker container!

This project is built on top of upstream project: kholia/OSX-KVM

Please read before posting. I already mentioned it and it doesn't solve the issue as it runs Docker inside Linux VM inside macOS VM as Docker container.

Sorry, but this thread is so long, and your answer was under spoiler. You can check that on this screen:

[grigorye]

Just to let you know, on macOS, we're experimenting with a custom shim for bash that lets us employ local "runners" (setup from the pool of dedicated macOS users) over ssh. We did not get it to perfection atm, but you get the idea.

[ChristopherHX]

I finally created a PR of my non docker execution environment: #1293, based on my initial work #97 (comment)

This just runs commands on your host device, without any virtualization technology. If you want to exec commands on a VM, just download act to it and run it there. Docker actions are not supported.

Maybe you can help finding bugs, because it has limited test cases for non linux platforms.

[ChrisKader]

As for Windows, we could go the route of Docker Desktop or the even cooler route of "forcing" docker to run inside a WSL 2 container so we then can have windows running WSL 2 which then has a docker instance to then run windows VMs.

[lublak]

what about https://hub.docker.com/_/microsoft-windows-base-os-images windows based images to have a "real" runner?

[duolabmeng6]

I also need to run tests in macos. I want to build software that I hope can support.

[honeyspoon]

TLDR;
act -P macos-latest=-self-hosted

For anybody looking at this in the future and wants to run their actions that require macOS like building and iOS app.
You can do it locally with that command.

[melMass]

I think this should be stated in the readme directly, you are linking this issue while the flag in the title does not exist

[NewtonChutney]

TLDR;
act -P macos-latest=-self-hosted

Is Windows support added too.. as like MacOS?

[ChristopherHX]

There are a lot more possibilities to use that experimental mode.

Just to name a few

act -P windows-latest=-self-hosted
act -P ubuntu-latest=-self-hosted
act -P macos-latest=-self-hosted
act -P freebsd-latest=-self-hosted

<label>=-self-hosted, <label> can be replaced by what you use in runs-on. Due to a bug in act choose only one of possible many labels of your runs-on. E.g. runs-on: [abc, bcd] both -P abc=-self-hosted and -P bcd=-self-hosted would work.

You must be running act on that operating system or it is logically wrong. The -self-hosted pseudo image platform is a replacement for the docker image normally used inside that option.

Problems with --no-container and why it doesn't exist yet.

• What if you use a self-hosted Runner with a custom runner label?
• Should act run all platforms on your host including those logging unsupported? That would run macOS jobs on a windows rost and vice versa.

Never heard from freebsd-latest? It's a possible platform like solaris, netbsd, plan9 and more in github-act-runner a self-hosted runner for GitHub Actions using their protocol for accepting jobs

This is experimental, almost no tests run in CI for macos and windows in that mode. I wouldn't use the word supported in this context

The ci checks of this experimental mode are not required, that means if dependablebot opens a PR whichs breaks the mode it will be merged without waiting for any maintainer