mirror of
https://github.com/nektos/act.git
synced 2026-04-26 01:15:51 +03:00
[GH-ISSUE #2105] Request for Support: Integration of Cirruslabs/Tart with Nektos/Act #1005
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#1005
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @triggered96 on GitHub (Nov 27, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/2105
Dear Nektos/Act Team,
I hope this message finds you well. I am writing to bring your attention to the incredible capabilities of Cirruslabs/Tart, a virtualization toolset designed for building, running, and managing macOS and Linux virtual machines (VMs) on Apple Silicon. This tool, crafted by CI engineers, offers exceptional advantages for automation needs.
Key Advantages of Tart:
Near-Native Performance: Tart utilizes Apple's Virtualization.Framework, ensuring near-native performance.
OCI-Compatible Registry Support: It enables the seamless push/pull of virtual machines from any OCI-compatible container registry.
Automated VM Creation: Tart provides a Packer Plugin for streamlined and automated VM creation.
CI System Integration: It easily integrates with any CI system for enhanced automation workflows.
Cirrus Runners Service: Tart powers the Cirrus Runners service, offering a substantial performance boost (2-3 times) over standard GitHub-hosted runners at a more cost-effective rate.
Given the success of the gitlab-tart-executor in supporting GitLab, I am reaching out to kindly request support for Tart in the context of Nektos/Act. The integration of Tart with Nektos/Act would open up new possibilities for users seeking a powerful and efficient virtualization solution within their CI/CD pipelines.
Cirruslabs/tart
Nektos/act
Your consideration of this request is highly appreciated, and I believe that the collaboration between Nektos/Act and Cirruslabs/Tart could greatly benefit the developer community.
Thank you for your time and consideration. I am happy to provide any additional information or assistance needed.
@fkorotkov commented on GitHub (Nov 27, 2023):
Tart maintainer here. 👋 We'll be great to see something like the following to be supported.
We are willing to help in any capacity if
actcommunity feels Tart support will be useful for running macOS actions locally.@ChristopherHX commented on GitHub (Nov 27, 2023):
Me from my part are unable to develop for the apple m-series platform. Assuming there is no simulator of tart for macOS 14 intel / linux intel or arm64 / windows intel.
We will see if other act maintainer / the owner would comment here.
via
Might be more act style. The problem with
-P macos-latest=ghcr.io/cirruslabs/macos-sonoma-xcode:latestis act would need to inspect the oci manifest to detect which tool to use.Oh
runs-on: ghcr.io/cirruslabs/macos-sonoma-xcode:latestis possible via the autoscaler of tart for GitHub Actions, I didn't see much runtime labels before.This means runtime label should be added to act? Currently act has a fall through to "skip unsupported platform"
Wouldn't this still require to check if the runtime label could be run with tart?
The most trivial way of using tart with current act is the following
via the act command running in the tart vm
For example you could mount your project workspace into tart and run act inside tart.
I'm grateful that cirruslabs provided me access to an apple m-series ci at no fee, however I still don't have any developing system for the macOS m-series platform. Would mean for me to need to borrow the personal macbook of my brother
@triggered96 commented on GitHub (Nov 27, 2023):
Self-host is indeed the less invasive approach at present, but its isolation is not good. It is easy to damage the host environment. The reason why I recommend integrating tart is because the container started by tart can have a good isolation environment, and tart starts very quickly, almost starting in 3 seconds. Currently only github and gitlab are supported, but I hope I can also add support for act.
@ChristopherHX commented on GitHub (Nov 27, 2023):
Yeah that's true. I meant to run act inside of tart to use the VM as the host environment. As long you don't delete your own workspace inside of the tart vm.
What kind of communication channels does tart support?
tart runtogether with an cli program to run? like docker, sshDoing this without mounting the act binary into the tart vm, would mean a lot of new logic for an executor. However then we don't have the problem to share state between jobs. It's a challenge.
I guess an ssh executor with some cli commands before and after the job could also make this work, then I'm at least able to help you.
I'm not familar with tart, nor can I run it to figure it out myself.
@triggered96 commented on GitHub (Nov 27, 2023):
I think tart should be used as an external binary mode, similar to docker, instead of integrating tart source code into act. tart has a command mode similar to docker. You can also mount directories and log in via ssh. Please refer to https://github.com/cirruslabs/gitlab-tart-executor and https://tart.run/quick-start/
Try running a Tart VM on your Apple Silicon device running macOS 13.0 (Ventura) or later (will download a 25 GB image):
Manual installation from a release archive
SSH access¶
If the guest VM is running and configured to accept incoming SSH connections you can conveniently connect to it like so:
Running scripts inside Tart virtual machines
We recommend using Cirrus CLI to run scripts and/or retrieve artifacts from within Tart virtual machines. Alternatively, you can use plain ssh connection and tart ip command:
Mounting directories¶
To mount a directory, run the VM with the --dir argument:
Here, the project specifies a mount name, whereas the ~/src/project is a path to the host's directory to expose to the VM.
It is also possible to mount directories in read-only mode by adding a third parameter, ro:
To mount multiple directories, repeat the --dir argument for each directory:
Note that the first parameter in each --dir argument must be unique, otherwise only the last --dir argument using that name will be used.
Note: to use the directory mounting feature, the host needs to run macOS 13.0 (Ventura) or newer.
Accessing mounted directories in macOS guests¶
All shared directories are automatically mounted to /Volumes/My Shared Files directory.
The directory we've mounted above will be accessible from the /Volumes/My Shared Files/project path inside a guest VM.
Note: to use the directory mounting feature, the guest VM needs to run macOS 13.0 (Ventura) or newer.
Changing mount location
Accessing mounted directories in Linux guests¶
To be able to access the shared directories from the Linux guest, you need to manually mount the virtual filesystem first:
mount -t virtiofs com.apple.virtio-fs.automount /mnt/shared
The directory we've mounted above will be accessible from the /mnt/shared/project path inside a guest VM.
@ChristopherHX commented on GitHub (Nov 27, 2023):
I guess copying this file into act is the easiest
https://github.com/cirruslabs/gitlab-tart-executor/blob/main/internal/tart/vm.go
I fear
/Volumes/My Shared Filescan cause issues in act, because not every code might behave correctly with spaces in paths.@triggered96 commented on GitHub (Nov 27, 2023):
I have it running fine on gitlab, no problems with
/Volumes/My Shared Files. I'm sure of this.@triggered96 commented on GitHub (Nov 27, 2023):
"Tart and Docker are indeed very similar. Apart from the initial image retrieval over the network, the key distinction lies in the speed of container startup. Testing on my machine revealed that starting a new Tart container takes around 3 seconds. With such speed, I can build the desired project in a new container environment. One major advantage of containers is their isolation, ensuring that each build runs in a new and clean container environment. This aligns with the original intention of Act, and this is made possible by Apple's disk read speed."
@ChristopherHX commented on GitHub (Nov 28, 2023):
For example a step like (syntax construct may not exist in gitlab, act partially implements actions)
May end up internally as
If you run that in a terminal window you will see what I mean.
This kind of problem might exits in more places..
Most will probably work most of the time...
I can probably try to create a poc but someone else need to test that on am m1..
@triggered96 commented on GitHub (Nov 28, 2023):
Just add
\before the space to solve the problem@triggered96 commented on GitHub (Dec 1, 2023):
https://github.com/cirruslabs/cirrus-cli/tree/master/internal/executor/instance/persistentworker/isolation/tart
https://github.com/cirruslabs/cirrus-cli/blob/master/internal/executor/instance/persistentworker/isolation/tart/tart.go
@ChristopherHX commented on GitHub (Dec 4, 2023):
I have created a branch with some code from the gitlab executor, I will continue at a later point of time. It's much easier with the hardware so you can actually run code, nothing to test at the moment.
I would be glad about a tart cli stub for macOS / Linux so testing doesn't require a real mac. AFAIK tart in tart is not possible so cirrus ci is not an option for tests with tart.
@oilrich25 commented on GitHub (Dec 5, 2023):
great. I have also been paying attention to tart. I have an m2 macmini and I can provide you with any testing needs.
@oilrich25 commented on GitHub (Dec 5, 2023):
I have installed tart. How do you currently use act to test tart?
@ChristopherHX commented on GitHub (Dec 5, 2023):
I haven't tested anything with tart yet. If you are using my downstream go based runner projects you probably only need to write a small python / powershell script.
nektos/act itself is different, because it doesn't have any rpc concept to run the step runner in a different environment.
remote ssh access would help me to get this working, due to the nature of tart it have to be outside of a VM. I'm not yet at the point to want to buy hardware to add support.
@oilrich25 commented on GitHub (Dec 5, 2023):
I saw act added pkg
https://github.com/nektos/act/commit/e50d11a4e68ab0697efdbe2df2449a557700da29for tart.If act is used, a
~/.actrcfile should be provided.As for finding hardware, you can rent Amazon macOS service, which provides M2 hardware. Details https://aws.amazon.com/ec2/instance-types/mac/.
Or I will test the application you provided, and if there are any problems, I will respond to you immediately😁
@oilrich25 commented on GitHub (Dec 10, 2023):
If it is a shared file system, it has been tested by me. The following method was found to be feasible.
It is recommended to make a soft link
ln -s /Volumes/My\ Shared\ Files/_work /private/tmp/_work@ChristopherHX commented on GitHub (Aug 23, 2024):
Long ago, I'm now working on this with a test system for this weekend.
worker script of
github-act-runner run --worker-args bash,/path/to/tart-worker.sh@ChristopherHX commented on GitHub (Aug 23, 2024):
....https://github.com/nektos/act/tree/act-tart updated.....
Known issue code copied from gitlab leaks process handles of tart, so I have to usually run "pkill tart".
I have no idea if the gitlab runner has not such an issue after 3+ runs, but maybe they fixed it or whatever
@ChristopherHX commented on GitHub (Aug 24, 2024):