[GH-ISSUE #97] Add support for --no-container to run windows/macos #63

Closed
opened 2026-03-01 21:39:34 +03:00 by kerem · 69 comments
Owner

Originally created by @chenrui333 on GitHub (Feb 24, 2020).
Original GitHub issue: https://github.com/nektos/act/issues/97

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

Originally created by @chenrui333 on GitHub (Feb 24, 2020). Original GitHub issue: https://github.com/nektos/act/issues/97 Thanks for creating this wonderful tool. It would be nice to have MacOS also supported as well.
Author
Owner

@cplee commented on GitHub (Feb 24, 2020):

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?

<!-- gh-comment-id:590395515 --> @cplee commented on GitHub (Feb 24, 2020): 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?
Author
Owner

@fwilhe commented on GitHub (Mar 10, 2020):

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?

<!-- gh-comment-id:597284703 --> @fwilhe commented on GitHub (Mar 10, 2020): 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?
Author
Owner

@cplee commented on GitHub (Apr 16, 2020):

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.

<!-- gh-comment-id:614935551 --> @cplee commented on GitHub (Apr 16, 2020): 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.
Author
Owner

@albertofem commented on GitHub (Apr 28, 2020):

@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.

<!-- gh-comment-id:620731202 --> @albertofem commented on GitHub (Apr 28, 2020): @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.
Author
Owner

@cplee commented on GitHub (May 13, 2020):

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

<!-- gh-comment-id:628271604 --> @cplee commented on GitHub (May 13, 2020): @albertofem - this looks really promising! What do you think about also supporting `--no-container` to force the platform to be `host`?
Author
Owner

@jcansdale commented on GitHub (May 14, 2020):

@cplee,

I've been experimenting with running act inside GitHub Codespaces.

image

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.

<!-- gh-comment-id:628469621 --> @jcansdale commented on GitHub (May 14, 2020): @cplee, I've been experimenting with running `act` inside GitHub Codespaces. ![image](https://user-images.githubusercontent.com/11719160/81909332-5c1fbf80-95c2-11ea-9a61-58e57409fada.png) 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.
Author
Owner

@fwilhe commented on GitHub (May 14, 2020):

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.

<!-- gh-comment-id:628473143 --> @fwilhe commented on GitHub (May 14, 2020): 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.
Author
Owner

@jcansdale commented on GitHub (May 14, 2020):

@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. 🤔

<!-- gh-comment-id:628653586 --> @jcansdale commented on GitHub (May 14, 2020): @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. 🤔
Author
Owner

@albertofem commented on GitHub (May 16, 2020):

@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.

<!-- gh-comment-id:629617369 --> @albertofem commented on GitHub (May 16, 2020): @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.
Author
Owner

@github-actions[bot] commented on GitHub (Jul 16, 2020):

Issue is stale and will be closed in 7 days unless there is new activity

<!-- gh-comment-id:659081170 --> @github-actions[bot] commented on GitHub (Jul 16, 2020): Issue is stale and will be closed in 7 days unless there is new activity
Author
Owner

@fwilhe commented on GitHub (Jul 16, 2020):

Not stale. Any updates?

<!-- gh-comment-id:659211660 --> @fwilhe commented on GitHub (Jul 16, 2020): Not stale. Any updates?
Author
Owner

@github-actions[bot] commented on GitHub (Sep 15, 2020):

Issue is stale and will be closed in 7 days unless there is new activity

<!-- gh-comment-id:692387266 --> @github-actions[bot] commented on GitHub (Sep 15, 2020): Issue is stale and will be closed in 7 days unless there is new activity
Author
Owner

@jcansdale commented on GitHub (Sep 15, 2020):

Still watching and hoping. 🙂

<!-- gh-comment-id:692547537 --> @jcansdale commented on GitHub (Sep 15, 2020): Still watching and hoping. 🙂
Author
Owner

@github-actions[bot] commented on GitHub (Jan 8, 2021):

Issue is stale and will be closed in 7 days unless there is new activity

<!-- gh-comment-id:756474946 --> @github-actions[bot] commented on GitHub (Jan 8, 2021): Issue is stale and will be closed in 7 days unless there is new activity
Author
Owner

@adnathanail commented on GitHub (Jan 11, 2021):

I still care!

<!-- gh-comment-id:758108522 --> @adnathanail commented on GitHub (Jan 11, 2021): I still care!
Author
Owner

@jonioni commented on GitHub (Feb 1, 2021):

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

<!-- gh-comment-id:771149128 --> @jonioni commented on GitHub (Feb 1, 2021): Still care +1. This may also solve certain scenarios as in #119 and #107 without having to download a 20GB image.
Author
Owner

@Segfaultd commented on GitHub (Feb 3, 2021):

Still care

<!-- gh-comment-id:772593781 --> @Segfaultd commented on GitHub (Feb 3, 2021): Still care
Author
Owner

@vdo commented on GitHub (Feb 4, 2021):

I still care

<!-- gh-comment-id:773347834 --> @vdo commented on GitHub (Feb 4, 2021): I still care
Author
Owner

@catthehacker commented on GitHub (Feb 4, 2021):

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

<!-- gh-comment-id:773493971 --> @catthehacker commented on GitHub (Feb 4, 2021): 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
Author
Owner

@github-actions[bot] commented on GitHub (Mar 11, 2021):

Issue is stale and will be closed in 14 days unless there is new activity

<!-- gh-comment-id:796318037 --> @github-actions[bot] commented on GitHub (Mar 11, 2021): Issue is stale and will be closed in 14 days unless there is new activity
Author
Owner

@catthehacker commented on GitHub (Mar 11, 2021):

Not stale. Just busy. 😔

<!-- gh-comment-id:796543832 --> @catthehacker commented on GitHub (Mar 11, 2021): Not stale. Just busy. 😔
Author
Owner

@honeyspoon commented on GitHub (Apr 7, 2021):

any way we could use this for macos on linux?
https://github.com/sickcodes/Docker-OSX

<!-- gh-comment-id:814881872 --> @honeyspoon commented on GitHub (Apr 7, 2021): any way we could use this for macos on linux? https://github.com/sickcodes/Docker-OSX
Author
Owner

@catthehacker commented on GitHub (Apr 7, 2021):

@hnspn act currently doesn't support running workflows without Docker.

<!-- gh-comment-id:815080352 --> @catthehacker commented on GitHub (Apr 7, 2021): @hnspn `act` currently doesn't support running workflows without Docker.
Author
Owner

@jacob-carlborg commented on GitHub (Apr 16, 2021):

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

<!-- gh-comment-id:821016040 --> @jacob-carlborg commented on GitHub (Apr 16, 2021): 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
Author
Owner

@catthehacker commented on GitHub (Apr 16, 2021):

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.

<!-- gh-comment-id:821027077 --> @catthehacker commented on GitHub (Apr 16, 2021): 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.
Author
Owner

@jacob-carlborg commented on GitHub (Apr 16, 2021):

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

<!-- gh-comment-id:821029688 --> @jacob-carlborg commented on GitHub (Apr 16, 2021): > 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
Author
Owner

@jacob-carlborg commented on GitHub (Apr 16, 2021):

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.

<!-- gh-comment-id:821032602 --> @jacob-carlborg commented on GitHub (Apr 16, 2021): 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.
Author
Owner

@catthehacker commented on GitHub (Apr 16, 2021):

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.

<!-- gh-comment-id:821032706 --> @catthehacker commented on GitHub (Apr 16, 2021): > 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.
Author
Owner

@catthehacker commented on GitHub (Apr 16, 2021):

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.

<!-- gh-comment-id:821033504 --> @catthehacker commented on GitHub (Apr 16, 2021): > 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.
Author
Owner

@jacob-carlborg commented on GitHub (Apr 16, 2021):

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.

<!-- gh-comment-id:821036109 --> @jacob-carlborg commented on GitHub (Apr 16, 2021): > 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.
Author
Owner

@catthehacker commented on GitHub (Apr 16, 2021):

Also, PSA: the issue is not stale. I didn't had much time to get back into drafting working PR (and because someone broke act on Windows which is my main dev machine, IntelliJ 🙏 please make proper SSH remote dev support like VSCode) but I've written quite a plan regarding this and other features and how to handle them properly so we don't get stuck with weird flags and implementations in future, just waiting for @cplee feedback if it looks all good and maybe later do something similar publicly to get feedback.

<!-- gh-comment-id:821041004 --> @catthehacker commented on GitHub (Apr 16, 2021): Also, PSA: the issue is not stale. I didn't had much time to get back into drafting working PR (and because someone broke `act` on Windows which is my main dev machine, IntelliJ 🙏 please make proper SSH remote dev support like VSCode) but I've written quite a plan regarding this and other features and how to handle them properly so we don't get stuck with weird flags and implementations in future, just waiting for @cplee feedback if it looks all good and maybe later do something similar publicly to get feedback.
Author
Owner

@ogvalt commented on GitHub (Apr 23, 2021):

Hi everyone,
Nice utility guys, really appreciate it.
But I've faced similar issue as the guys above, trying to run github actions on my local linux environment for package are going to be built for windows and macos.
So I've made little research and encountered Vagrant and Packer as kinda clues to how github actions could be mimiced fully locally.
Windows examples: https://github.com/devopsjourney1/packer-windows
Youtube explanation: https://www.youtube.com/watch?v=Cwk0ricWsiE

So, in the end of the day, I'd like to add my thoughts to this soup and I would be glad if they will help you and support for other platforms comes sooner. Hope if I'll be able to contribute in future :)

<!-- gh-comment-id:825495829 --> @ogvalt commented on GitHub (Apr 23, 2021): Hi everyone, Nice utility guys, really appreciate it. But I've faced similar issue as the guys above, trying to run github actions on my local linux environment for package are going to be built for windows and macos. So I've made little research and encountered Vagrant and Packer as kinda clues to how github actions could be mimiced fully locally. Windows examples: https://github.com/devopsjourney1/packer-windows Youtube explanation: https://www.youtube.com/watch?v=Cwk0ricWsiE So, in the end of the day, I'd like to add my thoughts to this soup and I would be glad if they will help you and support for other platforms comes sooner. Hope if I'll be able to contribute in future :)
Author
Owner

@jamiehankins commented on GitHub (May 12, 2021):

On the README.md at the project root, it says "Below platforms are currently unsupported and won't work (see issue #97)", which of course, is a link to this issue.

I don't really care about "--no-container", I just want to be able to use the "windows-latest" Docker image because that's what our GitHub actions use. That, of course, is if I'm understanding this (from our yml file) correctly.

    # Even though we build for multiple platforms, we only need to run
    # on a single host operating system. This is because we utilize cross-
    # build functionality of the dotnet build system.
    runs-on: windows-latest

Is this issue really related to this?

<!-- gh-comment-id:839991915 --> @jamiehankins commented on GitHub (May 12, 2021): On the README.md at the project root, it says "Below platforms are currently unsupported and won't work (see issue #97)", which of course, is a link to this issue. I don't really care about "--no-container", I just want to be able to use the "windows-latest" Docker image because that's what our GitHub actions use. That, of course, is if I'm understanding this (from our yml file) correctly. ``` # Even though we build for multiple platforms, we only need to run # on a single host operating system. This is because we utilize cross- # build functionality of the dotnet build system. runs-on: windows-latest ``` Is this issue really related to this?
Author
Owner

@catthehacker commented on GitHub (May 12, 2021):

@jamiehankins

Is this issue really related to this?

Not sure what you mean by that, but dotnet is not related at all to this project.

<!-- gh-comment-id:839994943 --> @catthehacker commented on GitHub (May 12, 2021): @jamiehankins > Is this issue really related to this? Not sure what you mean by that, but dotnet is not related at all to this project.
Author
Owner

@jamiehankins commented on GitHub (May 12, 2021):

Is this issue really related to this?

Not sure what you mean by that, but dotnet is not related at all to this project.

The README.md says "Below platforms are currently unsupported and won't work (see issue #97)". This is issue #97. One of the "(b)elow platforms" is "windows-latest".

I don't know what you mean by "dotnet is not related at all to this project." I'm not asking about dotnet. I'm asking how this issue is related to not being able to use the "windows-latest" Docker image, which is what my GitHub action needs.

<!-- gh-comment-id:840013041 --> @jamiehankins commented on GitHub (May 12, 2021): > > Is this issue really related to this? > > Not sure what you mean by that, but dotnet is not related at all to this project. The README.md says "Below platforms are currently unsupported and won't work (see issue #97)". This is issue #97. One of the "(b)elow platforms" is "windows-latest". I don't know what you mean by "dotnet is not related at all to this project." I'm not asking about dotnet. I'm asking how this issue is related to not being able to use the "windows-latest" Docker image, which is what my GitHub action needs.
Author
Owner

@catthehacker commented on GitHub (May 12, 2021):

Because running Windows docker containers is not implemented, that's why it says the platform is unsupported.

<!-- gh-comment-id:840013736 --> @catthehacker commented on GitHub (May 12, 2021): Because running Windows docker containers is not implemented, that's why it says the platform is unsupported.
Author
Owner

@damian123 commented on GitHub (May 13, 2021):

I am getting Skipping unsupported platform 'windows-latest' can this be fixed?

<!-- gh-comment-id:840431978 --> @damian123 commented on GitHub (May 13, 2021): I am getting Skipping unsupported platform 'windows-latest' can this be fixed?
Author
Owner

@catthehacker commented on GitHub (May 13, 2021):

I am getting Skipping unsupported platform 'windows-latest' can this be fixed?

No, please read my messages above

<!-- gh-comment-id:840438180 --> @catthehacker commented on GitHub (May 13, 2021): > I am getting Skipping unsupported platform 'windows-latest' can this be fixed? No, please read my messages above
Author
Owner

@Vishesh-Gupta commented on GitHub (Jun 8, 2021):

I have read through the discussion above and making act run on windows-latest definitely seems complex, but an interesting thing would be allowing it to connect to an Azure VM at users' request by using their tokens and credentials and running it in a VM on their account where it syncs up if the user wants to use windows-latest as the image and can run the action in such a way.

The Azure SDK has a go version https://github.com/Azure/azure-sdk-for-go which can help in setting this up. Furthermore, the VM machine can either be allowed control by the user or can be managed by act through the SDK. Not sure if this is feasible or what makes this infeasible for the act. Would appreciate a response on either

<!-- gh-comment-id:856469530 --> @Vishesh-Gupta commented on GitHub (Jun 8, 2021): I have read through the discussion above and making act run on windows-latest definitely seems complex, but an interesting thing would be allowing it to connect to an Azure VM at users' request by using their tokens and credentials and running it in a VM on their account where it syncs up if the user wants to use windows-latest as the image and can run the action in such a way. The Azure SDK has a go version https://github.com/Azure/azure-sdk-for-go which can help in setting this up. Furthermore, the VM machine can either be allowed control by the user or can be managed by act through the SDK. Not sure if this is feasible or what makes this infeasible for the act. Would appreciate a response on either
Author
Owner

@catthehacker commented on GitHub (Jun 8, 2021):

There are multiple interesting ways of implementing this, each with pros & cons but all of them depend on being actually written/implemented first.

Not sure if this is feasible or what makes this infeasible for the act.

Most likely paying for the resources in Azure?

I have to get back on that but it's been so much more important (and easier) to fix current issues than to implement new features.

<!-- gh-comment-id:856483063 --> @catthehacker commented on GitHub (Jun 8, 2021): There are multiple interesting ways of implementing this, each with pros & cons but all of them depend on being actually written/implemented first. > Not sure if this is feasible or what makes this infeasible for the act. Most likely paying for the resources in Azure? I have to get back on that but it's been so much more important (and easier) to fix current issues than to implement new features.
Author
Owner

@ChristopherHX commented on GitHub (Jun 30, 2021):

I started another atempt to implement something like --no-container as -P windows-latest=-self-hosted.
As of now it seems to be fully functional if you have node in version 12 in your PATH, before running it.
You cannot use any docker actions while using this self-hosted mode, this currently leads to undefined behavior.
You may have to change the default shell manually to cmd / pwsh or powershell on windows, because act doesn't check if bash exists.
actions/setup-node might alter the node version during a workflow run.
Some parts now even work on freebsd and other platforms (with stubbed docker support)
The self-hosted runner mode was tested by me on windows and freebsd.
I had to replace hardcoded file paths with dynamic ones and fix a huge number of bugs which aren't even reported yet.

PS C:\Users\Christopher\Downloads\acttest> ..\act.exe -P windows-latest=-self-hosted
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo"
[main.yml/windows] ⭐  Run actions/checkout@v2
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo"
[main.yml/windows]   ✅  Success - actions/checkout@v2
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo"
[main.yml/windows] ⭐  Run echo Hello World3
| Hello World3
[main.yml/windows]   ✅  Success - echo Hello World3
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git ref: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git ref: unable to find git repo"
[main.yml/windows] ⭐  Run dir
|  Volume in Laufwerk C: hat keine Bezeichnung.
|  Volumeseriennummer: 3E61-C6BE
|
|  Verzeichnis von C:\Users\Christopher\.cache\act\d1a916d6-c77e-49f8-8f22-bd87a29e6deb\hostexecutor
|
| 30.06.2021  22:38    <DIR>          .
| 30.06.2021  22:38    <DIR>          ..
| 30.06.2021  22:38    <DIR>          .github
|                0 Datei(en),              0 Bytes
|                3 Verzeichnis(se), 28.663.570.432 Bytes frei
[main.yml/windows]   ✅  Success - dir
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git ref: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git repo: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git revision: unable to find git repo"
time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git ref: unable to find git repo"
[main.yml/windows] ⭐  Run type .github\workflows\main.yml
| on: push
| defaults:
|   run:
|     shell: cmd
| jobs:
|   windows:
|     runs-on: windows-latest
|     steps:
|     - uses: actions/checkout@v2
|     - run: echo Hello World3
|     - run: dir
[main.yml/windows]   ✅  Success - type .github\workflows\main.yml
Error: error during connect: This error may indicate that the docker daemon is not running.: Get "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/volumes": open //./pipe/docker_engine: Das System kann die angegebene Datei nicht finden.

If you are interested, you find the code in my fork and a prebuild of act based on act v0.2.23.
Used by my self-hosted runner prototype for github (feature request of act) to have a native freebsd runner.
If my modification of act will ever going to be merged, it most likly will take over 6 month (One of my PR depends on another one e.g. this depends on #719).

<!-- gh-comment-id:871735094 --> @ChristopherHX commented on GitHub (Jun 30, 2021): I started another atempt to implement something like `--no-container` as `-P windows-latest=-self-hosted`. As of now it seems to be fully functional if you have `node` in version 12 in your PATH, before running it. **You cannot use any docker actions while using this self-hosted mode, this currently leads to undefined behavior.** **You may have to change the default shell manually to cmd / pwsh or powershell on windows, because act doesn't check if bash exists.** **`actions/setup-node` might alter the node version during a workflow run.** Some parts now even work on freebsd and other platforms (with stubbed docker support) The self-hosted runner mode was tested by me on windows and freebsd. I had to replace hardcoded file paths with dynamic ones and fix a huge number of bugs which aren't even reported yet. ``` PS C:\Users\Christopher\Downloads\acttest> ..\act.exe -P windows-latest=-self-hosted time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo" [main.yml/windows] ⭐ Run actions/checkout@v2 time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo" [main.yml/windows] ✅ Success - actions/checkout@v2 time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:58+02:00" level=warning msg="unable to get git ref: unable to find git repo" [main.yml/windows] ⭐ Run echo Hello World3 | Hello World3 [main.yml/windows] ✅ Success - echo Hello World3 time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git ref: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git ref: unable to find git repo" [main.yml/windows] ⭐ Run dir | Volume in Laufwerk C: hat keine Bezeichnung. | Volumeseriennummer: 3E61-C6BE | | Verzeichnis von C:\Users\Christopher\.cache\act\d1a916d6-c77e-49f8-8f22-bd87a29e6deb\hostexecutor | | 30.06.2021 22:38 <DIR> . | 30.06.2021 22:38 <DIR> .. | 30.06.2021 22:38 <DIR> .github | 0 Datei(en), 0 Bytes | 3 Verzeichnis(se), 28.663.570.432 Bytes frei [main.yml/windows] ✅ Success - dir time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git ref: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git repo: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git revision: unable to find git repo" time="2021-06-30T22:38:59+02:00" level=warning msg="unable to get git ref: unable to find git repo" [main.yml/windows] ⭐ Run type .github\workflows\main.yml | on: push | defaults: | run: | shell: cmd | jobs: | windows: | runs-on: windows-latest | steps: | - uses: actions/checkout@v2 | - run: echo Hello World3 | - run: dir [main.yml/windows] ✅ Success - type .github\workflows\main.yml Error: error during connect: This error may indicate that the docker daemon is not running.: Get "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/volumes": open //./pipe/docker_engine: Das System kann die angegebene Datei nicht finden. ``` If you are interested, you find [the code in my fork](https://github.com/ChristopherHX/act) and a [prebuild of act](https://github.com/ChristopherHX/act/actions/runs/987546131) based on act v0.2.23. _Used by [my self-hosted runner prototype for github](https://github.com/ChristopherHX/github-actions-act-runner) ([feature request of act](https://github.com/nektos/act/issues/706)) to have a native freebsd runner_. _If my modification of act will ever going to be merged, it most likly will take over 6 month (One of my PR depends on another one e.g. this depends on #719)._
Author
Owner

@fugkco commented on GitHub (Aug 17, 2021):

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.

<!-- gh-comment-id:900132052 --> @fugkco commented on GitHub (Aug 17, 2021): 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.
Author
Owner

@catthehacker commented on GitHub (Aug 17, 2021):

qemu has absolutely terrible performance and breaks easily

<!-- gh-comment-id:900139042 --> @catthehacker commented on GitHub (Aug 17, 2021): qemu has absolutely terrible performance and breaks easily
Author
Owner

@vniehues commented on GitHub (Dec 1, 2021):

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

<!-- gh-comment-id:983517676 --> @vniehues commented on GitHub (Dec 1, 2021): Are the plans to add support for windows & mac still active?
Author
Owner

@readefries commented on GitHub (Dec 1, 2021):

I'm also wondering that...

<!-- gh-comment-id:983518259 --> @readefries commented on GitHub (Dec 1, 2021): I'm also wondering that...
Author
Owner

@catthehacker commented on GitHub (Dec 1, 2021):

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

The issue is not closed so...

<!-- gh-comment-id:983540501 --> @catthehacker commented on GitHub (Dec 1, 2021): > Are the plans to add support for windows & mac still active? The issue is not closed so...
Author
Owner

@FranklinYu commented on GitHub (Dec 21, 2021):

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?

<!-- gh-comment-id:998519054 --> @FranklinYu commented on GitHub (Dec 21, 2021): > 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?
Author
Owner

@jacob-carlborg commented on GitHub (Dec 21, 2021):

macOS on QEMU on KVM is against Apple EULA

You're allowed to virtualize macOS on Apple hardware.

<!-- gh-comment-id:998520608 --> @jacob-carlborg commented on GitHub (Dec 21, 2021): > macOS on QEMU on KVM is against Apple EULA You're allowed to virtualize macOS on Apple hardware.
Author
Owner

@FranklinYu commented on GitHub (Dec 21, 2021):

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).

<!-- gh-comment-id:998524893 --> @FranklinYu commented on GitHub (Dec 21, 2021): > 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).
Author
Owner

@fugkco commented on GitHub (Dec 21, 2021):

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.

<!-- gh-comment-id:998554235 --> @fugkco commented on GitHub (Dec 21, 2021): > 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.
Author
Owner

@fugkco commented on GitHub (Dec 21, 2021):

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.

<!-- gh-comment-id:998556651 --> @fugkco commented on GitHub (Dec 21, 2021): > 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.
Author
Owner

@jacob-carlborg commented on GitHub (Dec 21, 2021):

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.

<!-- gh-comment-id:998925235 --> @jacob-carlborg commented on GitHub (Dec 21, 2021): > 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.
Author
Owner

@davetapley commented on GitHub (Jan 6, 2022):

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

<!-- gh-comment-id:1006802512 --> @davetapley commented on GitHub (Jan 6, 2022): Just to throw it out there: If ⬇️ ever gets done then that might be another way to support Windows runners? - https://github.com/docker/roadmap/issues/138
Author
Owner

@Lewiscowles1986 commented on GitHub (Mar 20, 2022):

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).

<!-- gh-comment-id:1073214042 --> @Lewiscowles1986 commented on GitHub (Mar 20, 2022): 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).
Author
Owner

@catthehacker commented on GitHub (Mar 20, 2022):

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.

<!-- gh-comment-id:1073259798 --> @catthehacker commented on GitHub (Mar 20, 2022): > 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.
Author
Owner

@Lewiscowles1986 commented on GitHub (Mar 20, 2022):

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.

<!-- gh-comment-id:1073354353 --> @Lewiscowles1986 commented on GitHub (Mar 20, 2022): 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.
Author
Owner

@lotyp commented on GitHub (May 1, 2022):

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

<!-- gh-comment-id:1114242780 --> @lotyp commented on GitHub (May 1, 2022): 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
Author
Owner

@catthehacker commented on GitHub (May 1, 2022):

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.

<!-- gh-comment-id:1114250529 --> @catthehacker commented on GitHub (May 1, 2022): > Maybe this can help ? [sickcodes/Docker-OSX](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: [kholia/OSX-KVM](https://github.com/kholia/OSX-KVM) Please read before posting. [I already mentioned it](https://github.com/nektos/act/issues/97#issuecomment-821033504) and it doesn't solve the issue as it runs Docker inside Linux VM inside macOS VM as Docker container.
Author
Owner

@lotyp commented on GitHub (May 13, 2022):

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:

image
<!-- gh-comment-id:1126322582 --> @lotyp commented on GitHub (May 13, 2022): > > Maybe this can help ? [sickcodes/Docker-OSX](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: [kholia/OSX-KVM](https://github.com/kholia/OSX-KVM) > > Please read before posting. [I already mentioned it](https://github.com/nektos/act/issues/97#issuecomment-821033504) 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: <img width="918" alt="image" src="https://user-images.githubusercontent.com/94047334/168344430-95490a9f-60ae-42ef-ba80-d1070b9dc933.png">
Author
Owner

@grigorye commented on GitHub (Jul 20, 2022):

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.

<!-- gh-comment-id:1189939176 --> @grigorye commented on GitHub (Jul 20, 2022): 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.
Author
Owner

@ChristopherHX commented on GitHub (Aug 6, 2022):

I finally created a PR of my non docker execution environment: https://github.com/nektos/act/pull/1293, based on my initial work https://github.com/nektos/act/issues/97#issuecomment-871735094

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.

<!-- gh-comment-id:1207285899 --> @ChristopherHX commented on GitHub (Aug 6, 2022): I finally created a PR of my non docker execution environment: https://github.com/nektos/act/pull/1293, based on my initial work https://github.com/nektos/act/issues/97#issuecomment-871735094 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.
Author
Owner

@ChrisKader commented on GitHub (Aug 16, 2022):

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.

<!-- gh-comment-id:1217122474 --> @ChrisKader commented on GitHub (Aug 16, 2022): 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.
Author
Owner

@lublak commented on GitHub (Sep 7, 2022):

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

<!-- gh-comment-id:1239758179 --> @lublak commented on GitHub (Sep 7, 2022): what about https://hub.docker.com/_/microsoft-windows-base-os-images windows based images to have a "real" runner?
Author
Owner

@xwartz commented on GitHub (Sep 28, 2022):

any updates?

<!-- gh-comment-id:1260577621 --> @xwartz commented on GitHub (Sep 28, 2022): any updates?
Author
Owner

@duolabmeng6 commented on GitHub (Jun 16, 2023):

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

<!-- gh-comment-id:1595092664 --> @duolabmeng6 commented on GitHub (Jun 16, 2023): I also need to run tests in macos. I want to build software that I hope can support.
Author
Owner

@honeyspoon commented on GitHub (Jun 22, 2023):

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.

<!-- gh-comment-id:1603029917 --> @honeyspoon commented on GitHub (Jun 22, 2023): 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.
Author
Owner

@melMass commented on GitHub (Jul 24, 2023):

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

<!-- gh-comment-id:1647566047 --> @melMass commented on GitHub (Jul 24, 2023): I think this should be stated in the readme directly, you are linking this issue while the flag in the title does not exist
Author
Owner

@NewtonChutney commented on GitHub (Dec 25, 2023):

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

Is Windows support added too.. as like MacOS?

<!-- gh-comment-id:1868958911 --> @NewtonChutney commented on GitHub (Dec 25, 2023): > TLDR; > `act -P macos-latest=-self-hosted` Is Windows support added too.. as like MacOS?
Author
Owner

@ChristopherHX commented on GitHub (Dec 25, 2023):

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

<!-- gh-comment-id:1868974264 --> @ChristopherHX commented on GitHub (Dec 25, 2023): 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_
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/act#63
No description provided.