Docker images for MAUI development/building/testing
Test images are designed to help quickly stand up containers that are ready to use for running UI Tests with Appium on the Android Emulator. They come setup with Appium Server and the Android Emulator (for the given API level) both running and waiting when the container is started.
NOTE: Only
linux/amd64is available.
docker run `
-v C:/MyApp/bin/Debug/net9.0-android35.0/:/app `
--device /dev/kvm `
-p 5554:5554 `
-p 5555:5555 `
-p 4723:4723 `
redth/maui-testing:appium-emulator-linux-android35NOTE: Ports are mapped for the emulator, ADB, and Appium in this example.
NOTE: Device passthrough of
/dev/kvmis required for the emulator
The host folder with the built apk's can be mapped to a folder in the container. You can then specify the location of the apk to install to appium using the container's path to it (eg: /app/my.companyname.app-Signed.apk).
INIT_PWSH_SCRIPTOptionally (linux or windows images) specify a path to a .ps1 script file to run before starting the runner agent (Default path is/config/init.ps1on linux andC:\\config\\init.ps1on windows - you would need to bind a volume for the script to use)INIT_BASH_SCRIPTOptionally (linux image only) specify a path to a .ps1 script file to run before starting the runner agent (Default path is/config/init.shon linux - you would need to bind a volume for the script to use)
Each Android API Level (23 through latest) has its own image variant. You can specify different ones to use by the tag name (eg: test-linux:android23 or test-linux:android35).
Show All Variants...
The emulator on this image requires nested virtualization to work correctly. This is done by passing the --device /dev/kvm from the host device to the docker container.
Windows may have mixed results with Docker running in Hyper-V mode. It seems recent Windows and/or Docker updates makes this less reliable. Instead it's recommended to have Docker run in WSL2 mode and launch the docker image from WSL2 in order to pass through the KVM device.
Apple Silicon based Macs will require an M3 or newer to use nested virtualization with Docker.
Linux should work fine as long as you have kvm virtualization support enabled.
- Linux:
- Windows:
Runner images are intended to make it really easy to stand up self-hosted build agents with some .NET / MAUI SDK prerequisites installed. They have the latest workload set installed for the given .NET SDK version. They also install, configure (including self registration), and run the GitHub Action Runner service when the container starts.
docker run `
-e GITHUB_ORG=myorg
748B
`
-e GITHUB_REPO=myrepo `
-e GITHUB_TOKEN=myaccesstoken `
redth/maui-actions-runner:windows-dotnet9.0NOTE: You can omit the
GITHUB_REPOto install the runner at the organization level, but make sure you have an access token (PAT) with the correct access at this level to do so.
GITHUB_TOKENRequired github access token with Action Runner Read/Write permissons in order to self register the runner.GITHUB_ORGRequired github organization to attach the runner to.GITHUB_REPOOptional repository name to attach the runner to (otherwise attaches at the org level).RUNNER_NAMEOptionally sets an explicit runner name. Default is calculated based on a suffix, and random suffix.RUNNER_NAME_PREFIXOptional prefix to be used for the runner name.RANDOM_RUNNER_SUFFIXDefault istrue. If true, adds a random suffix to the RUNNER_NAME.LABELSOverrides the default set of labels to apply to the runner.RUNNER_GROUPOverrides the default runner group.RUNNER_WORKDIROverrides the default runner work directory.INIT_PWSH_SCRIPTOptionally (linux or windows images) specify a path to a .ps1 script file to run before starting the runner agent (Default path is/config/init.ps1on linux andC:\\config\\init.ps1on windows - you would need to bind a volume for the script to use)INIT_BASH_SCRIPTOptionally (linux image only) specify a path to a .ps1 script file to run before starting the runner agent (Default path is/config/init.shon linux - you would need to bind a volume for the script to use)
- Chocolatey
- Microsoft OpenJDK
- Android SDK
- .NET SDK
- .NET Workloads
NOTE: The .NET Workloads are installed with the latest Workload set version for the given .NET SDK major version (eg: 9.0 SDK could have 9.0.203 as the latest workload set version).
NOTE: Versions for things like OpenJDK and Android SDK (including the individual SDK packages/components) are inferred from the Workloads'
data/WorkloadDependencies.jsonfiles (in their Manifest nuget packages), which specify recommended versions and components to be installed for each workload.
The images can be built with their respective build.ps1 files. See the GitHub workflow yml files for examples.
- Windows container for Test images