act
act copied to clipboard
nektos
Add support for `--no-container` to run windows/macos
Thanks for creating this wonderful tool. It would be nice to have MacOS also supported as well.
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?
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?
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 I have a rough but working implementation I'm using locally to test some macOS-based actions. It should also be easy enough to have it working in Windows. Please take a look here:
https://github.com/nektos/act/compare/master...albertofem:feature/running_on_host?expand=1
If you think this approach is good, I'll go ahead and make the PR once I have a better implementation and have tested extensively on both Mac and Windows.
@albertofem - this looks really promising! What do you think about also supporting --no-container to force the platform to be host?
@cplee,
I've been experimenting with running act inside GitHub Codespaces.
If there was a --no-container option to run actions on the host VM, that would be great!
Unfortunately the actions/setup-dotnet action is failing at the moment. I'm guessing this will be the same for many setup actions.
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.
@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. 🤔
@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.
Issue is stale and will be closed in 7 days unless there is new activity
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Issue is stale and will be closed in 7 days unless there is new activity
Issue is stale and will be closed in 7 days unless there is new activity
Still care +1. This may also solve certain scenarios as in #119 and #107 without having to download a 20GB image.
Hi guys, can you please not spam/post unhelpful messages, it's creating unnecessary emails/notifications. Stalebot has been adjusted and it won't close the issue so fast like it did before so there is no need to bump all the time in such short period of time. as for the feature itself I'm working very slowly on implementing that in this (messy) branch: https://github.com/catthehacker/act-fork/tree/no-container
Issue is stale and will be closed in 14 days unless there is new activity
any way we could use this for macos on linux? https://github.com/sickcodes/Docker-OSX
@hnspn act currently doesn't support running workflows without Docker.
Regarding the --no-container flag. I think it would best to run the non-linux runners in a VM instead of directly on the host. For Windows xhyve [1] can be used. It's a very lightweight hypervisor built on top of the Apple's Hypervisor framework. For macOS, there's another project called Anka [2] which also provides very lightweight VMs. I've used xhyve, but not for Windows guests. It's quite fast, a FreeBSD guest boots in around 10 seconds. I have not used Anka.
[1] https://github.com/machyve/xhyve [2] https://veertu.com/download-anka-develop
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.
Docker supports Windows containers and that's something I want to implement but also give the ability to run actions directly on host.
If you would like to run them in VM, run act in VM.
Docker supports Windows containers
Isn't that only supported on Windows?
"Windows requires the host OS version to match the container OS version" [1] and:
$ uname
Darwin
$ docker run mcr.microsoft.com/windows/servercore:ltsc2019
Unable to find image 'mcr.microsoft.com/windows/servercore:ltsc2019' locally
ltsc2019: Pulling from windows/servercore
docker: no matching manifest for linux/amd64 in the manifest list entries.
See 'docker run --help'.
If you would like to run them in VM, run act in VM.
Yeah, that's a good point.
[1] https://hub.docker.com/_/microsoft-windows-base-os-images
Xhyve only works on macOS, I didn't think that through. Anka also only works on macOS but you're only allowed to virtualize macOS on a native Mac.
Isn't that only supported on Windows?
Yes, you can't run Windows Docker containers on any other OS than Windows since those don't have Windows kernel. Just like Linux containers work only on Linux.
"Windows requires the host OS version to match the container OS version"
With Hyper-V isolation it's possible to run other versions of Windows OS containers.
$ uname Darwin
Macs can't run anything on their own. Sorry.
Xhyve only works on macOS, I didn't think that through. Anka also only works on macOS but you're only allowed to virtualize macOS on a native Mac.
https://github.com/sickcodes/Docker-OSX
This is what I'm using for bare testing of MacOS, it kinda works but to run Docker (inside MacOS VM) you need Intel CPU for nested virtualisation
But I would like to not add any specific implementations for such weird hacks. All of that will work over SSH + DOCKER_HOST envvar.
https://github.com/sickcodes/Docker-OSX This is what I'm using for bare testing of MacOS, it kinda works but to run Docker (inside MacOS VM) you need Intel CPU for nested virtualisation
I see.