cross-platform-actions / action

Cross-platform GitHub action
MIT License
140 stars 19 forks source link

Cross-Platform GitHub Action

This project provides a GitHub action for running GitHub Actions workflows on multiple platforms, including platforms that GitHub Actions doesn't currently natively support.

Features

Some of the features that this action supports include:

Usage

Minimal Example

Here's a sample workflow file which will run the given commands on FreeBSD 14.0.

name: CI

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Test
        uses: cross-platform-actions/action@v0.25.0
        with:
          operating_system: freebsd
          version: '14.0'
          run: |
            uname -a
            echo $SHELL
            pwd
            ls -lah
            whoami
            env | sort

Full Example

Here's a sample workflow file which will set up a matrix resulting in four jobs. One which will run on FreeBSD 14.0, one which runs OpenBSD 7.6, one which runs NetBSD 10.0, one which runs OpenBSD 7.6 on ARM64 and one which runs NetBSD 10.0 on ARM64.

name: CI

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        os:
          - name: freebsd
            architecture: x86-64
            version: '14.1'

          - name: openbsd
            architecture: x86-64
            version: '7.6'

          - name: openbsd
            architecture: arm64
            version: '7.6'

          - name: netbsd
            architecture: x86-64
            version: '10.0'

          - name: netbsd
            architecture: arm64
            version: '10.0'

    steps:
      - uses: actions/checkout@v4

      - name: Test on ${{ matrix.os.name }}
        uses: cross-platform-actions/action@v0.25.0
        env:
          MY_ENV1: MY_ENV1
          MY_ENV2: MY_ENV2
        with:
          environment_variables: MY_ENV1 MY_ENV2
          operating_system: ${{ matrix.os.name }}
          architecture: ${{ matrix.os.architecture }}
          version: ${{ matrix.os.version }}
          shell: bash
          memory: 5G
          cpu_count: 4
          run: |
            uname -a
            echo $SHELL
            pwd
            ls -lah
            whoami
            env | sort

Different platforms need to run on different runners, so see the Runners section below.

Inputs

This section lists the available inputs for the action.

Input Required Default Value Type Description
run string Runs command-line programs using the operating system's shell. This will be executed inside the virtual machine.
operating_system string The type of operating system to run the job on. See Supported Platforms.
architecture x86-64 string The architecture of the operating system. See Supported Platforms.
version string The version of the operating system to use. See Supported Platforms.
shell default string The shell to use to execute the commands. Defaults to the default shell for the given operating system. Allowed values are: default, sh and bash
environment_variables "" string A list of environment variables to forward to the virtual machine. The list should be separated with spaces. The CI and any environment variables starting with GITHUB_ are forwarded automatically.
memory 6G string The amount of memory for the virtual machine.
cpu_count 2 integer The number of CPU cores for the virtual machine.
image_url string URL a custom VM image that should be used in place of the default ones.
sync_files true string Specifies if the local files should be synchronized to the virtual machine and in which direction. Valid values are true, false, runner-to-vm and vm-to-runner. true synchronizes files in both directions. false disables file synchronization.
shutdown_vm true boolean Specifies if the VM should be shutdown after the action has been run.

All inputs are expected to be of the specified type. It's especially important that you specify version as a string, using single or double quotes. Otherwise YAML might interpet the value as a numeric value instead of a string, which leads to some unexpected behavior. If the version is specified as version: 13.0, YAML will interpet 13.0 as a floating point number, drop the fraction part (because 13 and 13.0 are the same) and the GitHub action will only see 13 instead of 13.0. The solution is to explicitly state that a string is required by using quotes: version: '13.0'.

Custom VM Image (image_url)

With the image_url input it's possible to specify a custom virtual machine image. The main reason for this feature is to do additional custom provisioning, like installing additional packages. This allows to pre-install everything that is needed for a CI job beforhand, which can save time later when the job is run.

Only existing operating systems, architectures and versions are supported.

Building a Custom VM Image
  1. Fork one of the existing *builder repositories
  2. Add the additional provisioning to the resources/custom.sh script. Don't remove any existing provisioning scripts.
  3. Adjust the CI workflow to remove any unwanted architectures or versions
  4. Create and push a new tag
  5. This will launch the CI workflow, build the image(s) and create a draft GitHub release. The VM image(s) are automatically attached to the release
  6. Edit the release to publish it
  7. Copy the URL for the VM image
  8. Use the URL with the image_url input

Supported Platforms

This sections lists the currently supported platforms by operating system. Each operating system will list which versions are supported.

OpenBSD (openbsd)

Version x86-64 arm64
7.6
7.5
7.4
7.3
7.2
7.1
6.9
6.8

FreeBSD (freebsd)

Version x86-64 arm64
14.1
14.0
13.4
13.3
13.2
13.1
13.0
12.4
12.2

NetBSD (netbsd)

Version x86-64 arm64
10.0
9.4
9.3
9.2

Architectures

This section lists the supported architectures and any aliases. All the names are case insensitive. For a combination of supported architectures and operating systems, see the sections for each operating system above.

Architecture Aliases
arm64 aarch64
x86-64 x86_64, x64

Hypervisors

This section lists the available hypervisors, which platforms they can run and which runners they can run on.

Hypervisor Linux Runner FreeBSD OpenBSD Other Platforms
qemu

Runners

This section lists the different combinations of platforms and on which runners they can run.

Runner OpenBSD FreeBSD NetBSD ARM64
Linux

Linux on Non-x86 Architectures

There are currently no plans to add support for Linux. Instead it's very easy to support Linux on non-x86 architectures using the QEMU support in Docker with the docker/setup-qemu-action action:

- name: Set up QEMU
  uses: docker/setup-qemu-action@v3
  with:
    platforms: linux/riscv64

- name: Run Command in Docker
  run: |
    docker run \
      --rm \
      -v $(pwd):/${{ github.workspace }} \
      -w ${{ github.workspace }} \
      --platform linux/riscv64 \
      debian:unstable-slim \
      <command to run>

For those not familiar with Docker, here's an explanation of the above command:

Under the Hood

GitHub Actions currently only support macOS, Linux, and Windows. To be able to run other platforms, this GitHub action runs the commands inside a virtual machine (VM). If the host platform is macOS or Linux the hypervisor can take advantage of nested virtualization.

All platforms run on the QEMU hypervisor. QEMU is a general purpose hypervisor and emulator that runs on most host platforms and supports most guest systems.

The VM images running inside the hypervisor are built using Packer. It's a tool for automatically creating VM images, installing the guest operating system and doing any final provisioning.

The GitHub action uses SSH to communicate and execute commands inside the VM. It uses rsync to share files between the guest VM and the host. To authenticate the SSH connection a unique key pair is used. This pair is generated each time the action is run. The public key is added to the VM image and the host stores the private key. A secondary hard drive, which is backed by a file, is created. The public key is stored on this hard drive, which the VM then mounts. At boot time, the secondary hard drive will be identified and the public key will be copied to the appropriate location.

To reduce the time it takes for the GitHub action to start executing the commands specified by the user, it aims to boot the guest operating systems as fast as possible. This is achieved in a couple of ways:

Local Development

Prerequisites

Instructions

  1. Install the above prerequisites

  2. Clone the repository by running:

    git clone https://github.com/cross-platform-actions/action
  3. Navigate to the newly cloned repository: cd action

  4. Install the dependencies by running: npm install

  5. Run any of the below npm commands

npm Commands

The following npm commands are available:

Running End to End Tests

The end to end tests can be run locally by running it through Act. By default, resources and VM images will be downloaded from github.com. By running a local HTTP server it's possible to point the GitHub action to local resources.

Prerequisites

Instructions

  1. Install the above prerequisites

  2. Copy test/workflows/ci.yml.example to test/workflows/ci.yml

  3. Make any changes you like to test/workflows/ci.yml, this is file ignored by Git

  4. Build the GitHub action by running: npm run build

  5. Package the GitHub action by running: npm run package

  6. Run the GitHub action by running: act --privileged -W test/workflows

Providing Resources Locally

The GitHub action includes a development dependency on a HTTP server. The test/http directory contains a skeleton of a directory structure which matches the URLs that the GitHub action uses to download resources. All files within the test/http are ignore by Git.

  1. Add resources as necessary to the test/http directory

  2. In one shell, run the following command to start the HTTP server:

    ./node_modules/http-server/bin/http-server test/http -a 127.0.0.1

    The -a flag configures the HTTP server to only listen for incoming connections from localhost, no external computers will be able to connect.

  3. In another shell, run the GitHub action by running:

    act --privileged -W test/workflows --env CPA_RESOURCE_URL=<url>

    Where <url> is the URL inside Docker that points to localhost of the host machine, for macOS, this is http://host.docker.internal:8080. By default, the HTTP server is listening on port 8080.