Request for Support: Integration of Cirruslabs/Tart with Nektos/Act about act HOT 17 OPEN

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.

• We need to mount the HostEnviroment scratch space
• We need to add a path translation mapping, due to mount path restrictions
• We might need to map tarts mount path of the vm path back to the host filesystem, due to filesystem mounting and the code expects that we can directly copy into the container filesystem using the destination path inside the container.

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.

from act.

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.

• We need to mount the HostEnviroment scratch space
• We need to add a path translation mapping, due to mount path restrictions
• We might need to map tarts mount path of the vm path back to the host filesystem, due to filesystem mounting and the code expects that we can directly copy into the container filesystem using the destination path inside the container.

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.

great. I have also been paying attention to tart. I have an m2 macmini and I can provide you with any testing needs.

from act.

Tart maintainer here. 👋 We'll be great to see something like the following to be supported.

name: Tests
jobs:
  test:
    runs-on: ghcr.io/cirruslabs/macos-sonoma-xcode:latest

We are willing to help in any capacity if act community feels Tart support will be useful for running macOS actions locally.

from act.

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.

name: Tests
jobs:
  test:
    runs-on: macos-latest
    ....

via

act -P macos-latest=tart://ghcr.io/cirruslabs/macos-sonoma-xcode:latest

Might be more act style. The problem with -P macos-latest=ghcr.io/cirruslabs/macos-sonoma-xcode:latest is act would need to inspect the oci manifest to detect which tool to use.

Oh runs-on: ghcr.io/cirruslabs/macos-sonoma-xcode:latest is 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

name: Tests
jobs:
  test:
    runs-on: macos-latest
    ....

via the act command running in the tart vm

act -P macos-latest=-self-hosted

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

from act.

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.

from act.

Self-host is indeed the less invasive approach at present, but its isolation is not good

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?

• stdin / stdout redirection of tart run together with an cli program to run? like docker, ssh
  • or do we need to connect via ssh
  • This can be used to tranfer every job into a separate tart vm and allow to send cancellation via stdin
  • Then I would need to know the required cli commands
• Can tart access the ip addr of the host? I think act --help shows the ip I mean here, the outbound ip used to connect to external ip addresses. Obviously the spawned act inside the vm could replace the ip with a different one using the command of the docs.
• I think it is needed to bind mount the workspace of act into every job, mounting it readonly is enough.

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

from act.

Self-host is indeed the less invasive approach at present, but its isolation is not good

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?

• stdin / stdout redirection of tart run together with an cli program to run? like docker, ssh

  • or do we need to connect via ssh
  • This can be used to tranfer every job into a separate tart vm and allow to send cancellation via stdin
  • Then I would need to know the required cli commands

• Can tart access the ip addr of the host? I think act --help shows the ip I mean here, the outbound ip used to connect to external ip addresses. Obviously the spawned act inside the vm could replace the ip with a different one using the command of the docs.

• I think it is needed to bind mount the workspace of act into every job, mounting it readonly is enough.

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

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/

$ tart -h
USAGE: tart <subcommand>

OPTIONS:
  --version               Show the version.
  -h, --help              Show help information.

SUBCOMMANDS:
  create                  Create a VM
  clone                   Clone a VM
  run                     Run a VM
  set                     Modify VM's configuration
  get                     Get a VM's configuration
  list                    List created VMs
  login                   Login to a registry
  logout                  Logout from a registry
  ip                      Get VM's IP address
  pull                    Pull a VM from a registry
  push                    Push a VM to a registry
  import                  Import VM from a compressed .tvm file
  export                  Export VM to a compressed .tvm file
  prune                   Prune OCI and IPSW caches or local VMs
  rename                  Rename a VM
  stop                    Stop a VM
  delete                  Delete a VM
  suspend                 Suspend a VM

  See 'tart help <subcommand>' for detailed help.

Try running a Tart VM on your Apple Silicon device running macOS 13.0 (Ventura) or later (will download a 25 GB image):

brew install cirruslabs/cli/tart
tart clone ghcr.io/cirruslabs/macos-sonoma-base:latest sonoma-base
tart run sonoma-base

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:

ssh admin@$(tart ip sonoma-base)

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:

brew install cirruslabs/cli/sshpass
sshpass -p admin ssh -o "StrictHostKeyChecking no" admin@$(tart ip sonoma-base) "uname -a"
sshpass -p admin ssh -o "StrictHostKeyChecking no" admin@$(tart ip sonoma-base) < script.sh

Mounting directories¶
To mount a directory, run the VM with the --dir argument:

tart run --dir=project:~/src/project vm

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:

tart run --dir=project:~/src/project:ro vm

To mount multiple directories, repeat the --dir argument for each directory:

tart run --dir=www1:~/project1/www --dir=www2:~/project2/www

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.

from act.

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 Files can cause issues in act, because not every code might behave correctly with spaces in paths.

from act.

I have it running fine on gitlab, no problems with /Volumes/My Shared Files. I'm sure of this.

I have it running fine on gitlab, no problems with/Volumes/My Shared Files. I'm sure of this.

from act.

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

Running with gitlab-runner 16.6.0 (3046fee8)
  on macOS-runner 7GL9LSi9, system ID: s_d58ff559ed4b

Preparing the "custom" executor
00:10
Using Custom executor...
2023/11/22 11:46:56 Pulling the latest version of macos-ventura-base...
2023/11/22 11:46:56 Cloning and configuring a new VM...
2023/11/22 11:46:56 Waiting for the VM to boot and be SSH-able...
2023/11/22 11:47:06 Was able to SSH!
2023/11/22 11:47:06 VM is ready.

Preparing environment
00:02
Running on admins-Virtual-Machine.local...

Getting source from Git repository
00:01
Fetching changes with git depth set to 20...
Initialized empty Git repository in /private/tmp/builds/triggered/actions-demo/.git/
Created fresh repository.
Checking out 4cb43aeb as detached HEAD (ref is master)...
Skipping Git submodules setup

Executing "step_script" stage of the job script
00:01
WARNING: Starting with version 17.0 the 'build_script' stage will be replaced with 'step_script': https://gitlab.com/groups/gitlab-org/-/epics/6112
$ uname -a
Darwin admins-Virtual-Machine.local 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:19 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_VMAPPLE arm64
Job succeeded

from act.

I have it running fine on gitlab, no problems with /Volumes/My Shared Files. I'm sure of this.

I have it running fine on gitlab, no problems with/Volumes/My Shared Files. I'm sure of this.

For example a step like (syntax construct may not exist in gitlab, act partially implements actions)

- run: somescript
  shell: bash -e {0}

May end up internally as

bash -e /Volumes/My Shared Files/path/to/script.sh

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

from act.

I have it running fine on gitlab, no problems with /Volumes/My Shared Files. I'm sure of this.

I have it running fine on gitlab, no problems with/Volumes/My Shared Files. I'm sure of this.

For example a step like (syntax construct may not exist in gitlab, act partially implements actions)

- run: somescript
  shell: bash -e {0}

May end up internally as

bash -e /Volumes/My Shared Files/path/to/script.sh

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

$ tart run  macos-ventura-base --dir .cache/

Last login: Tue Nov 28 21:43:30 on console
admin@admins-Virtual-Machine ~ % /Volumes/My\ Shared\ Files/act 
zsh: permission denied: /Volumes/My Shared Files/act
admin@admins-Virtual-Machine ~ % cd /Volumes/My\ Shared\ Files/act 
admin@admins-Virtual-Machine act % cat > shell.sh
echo "Hello" 
^C
admin@admins-Virtual-Machine act % bash -e /Volumes/My\ Shared\ Files/act/shell.sh
Hello
admin@admins-Virtual-Machine act % 

Just add \ before the space to solve the problem

from act.

I have it running fine on gitlab, no problems with /Volumes/My Shared Files. I'm sure of this.

I have it running fine on gitlab, no problems with/Volumes/My Shared Files. I'm sure of this.

For example a step like (syntax construct may not exist in gitlab, act partially implements actions)

- run: somescript
  shell: bash -e {0}

May end up internally as

bash -e /Volumes/My Shared Files/path/to/script.sh

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

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

from act.

I have installed tart. How do you currently use act to test tart?

from act.

How do you currently use act to test tart?

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.

great. I have also been paying attention to tart. I have an m2 macmini and I can provide you with any testing needs.

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.

from act.

How do you currently use act to test tart?

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.

great. I have also been paying attention to tart. I have an m2 macmini and I can provide you with any testing needs.

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.

I saw act added pkg https://github.com/nektos/act/commit/e50d11a4e68ab0697efdbe2df2449a557700da29 for tart.
If act is used, a ~/.actrc file should be provided.

# ~/.actrc
-P macos-latest=tart://ghcr.io/cirruslabs/macos-sonoma-xcode:latest

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😁

from act.

If it is a shared file system, it has been tested by me. The following method was found to be feasible.

oilrich25deMac-mini:Desktop oilrich25$ tart list
Source Name               Size State  
local  macos-ventura-base 20   stopped

oilrich25deMac-mini:Desktop oilrich25$ tart clone macos-ventura-base vm

oilrich25deMac-mini:Desktop oilrich25$ tart run --dir=_work:/Users/oilrich25/Desktop/gitea-actions-runner/actions-runner/_work vm

It is recommended to make a soft link ln -s /Volumes/My\ Shared\ Files/_work /private/tmp/_work

oilrich25deMac-mini:Desktop oilrich25$ sshpass -p admin ssh -o "StrictHostKeyChecking no" admin@$(tart ip vm) "ln -s /Volumes/My\ Shared\ Files/_work /private/tmp/_work"
oilrich25deMac-mini:Desktop oilrich25$ sshpass -p admin ssh -o "StrictHostKeyChecking no" admin@$(tart ip vm) "cd /private/tmp/_work/simple-go-action/simple-go-action/"
oilrich25deMac-mini:Desktop oilrich25$ sshpass -p admin ssh -o "StrictHostKeyChecking no" admin@$(tart ip vm) "cd /private/tmp/_work/simple-go-action/simple-go-action/ && pwd"
/private/tmp/_work/simple-go-action/simple-go-action

oilrich25deMac-mini:Desktop oilrich25$ sshpass -p admin ssh -o "StrictHostKeyChecking no" admin@$(tart ip vm) "cd /private/tmp/_work/simple-go-action/simple-go-action/ && ls"
CODE_OF_CONDUCT.md
CONTRIBUTING.md
LICENSE.txt
README.md
build-image.sh
image
shell.sh

oilrich25deMac-mini:Desktop oilrich25$ sshpass -p admin ssh -o "StrictHostKeyChecking no" admin@$(tart ip vm) "cd /private/tmp/_work/simple-go-action/simple-go-action/ && ./shell.sh"
/private/tmp/_work/simple-go-action/simple-go-action

from act.