Skip to content

Commit

Permalink
Merge branch 'weekly-cleanup/document-adding-test-runners-des-513'
Browse files Browse the repository at this point in the history
  • Loading branch information
MarkusPettersson98 committed Dec 14, 2023
2 parents 8894d51 + 7644269 commit 3fc2cb8
Show file tree
Hide file tree
Showing 6 changed files with 250 additions and 88 deletions.
10 changes: 10 additions & 0 deletions .github/workflows/desktop-e2e.yml
Original file line number Diff line number Diff line change
@@ -1,3 +1,11 @@
# Workflow for triggering `test-manager` on select platforms.
#
# This is a rather complex workflow. The complexity mainly stems from these sources:
# * figuring out which platforms to test on which runners (prepare-matrices)
# * figuring out if the app and e2e-tests should be built on the runner (build-{linux,windows,macos})
# or if we should download the artifacts from https://releases.mullvad.net/desktop/
# * compiling the output from the different runners and executed platforms.
---
name: Desktop - End-to-end tests
on:
schedule:
Expand All @@ -16,6 +24,8 @@ jobs:
- name: Generate matrix for Linux builds
shell: bash
run: |
# A list of VMs to run the tests on. These refer to the names defined
# in $XDG_CONFIG_DIR/mullvad-test/config.json on the runner.
all='["debian11","debian12","ubuntu2004","ubuntu2204","ubuntu2304","ubuntu2310","fedora39","fedora38","fedora37","fedora36"]'
oses="${{ github.event.inputs.oses }}"
echo "OSES: $oses"
Expand Down
4 changes: 2 additions & 2 deletions test/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,7 @@ TARGET=x86_64-pc-windows-gnu ./build.sh

# Building base images

See [`BUILD_OS_IMAGE.md`](./BUILD_OS_IMAGE.md) for how to build images for running tests on.
See [`BUILD_OS_IMAGE.md`](./docs/BUILD_OS_IMAGE.md) for how to build images for running tests on.

# Running tests

Expand All @@ -107,7 +107,7 @@ Here is an example of how to create a new OS configuration and then run all test

```bash
# Create or edit configuration
# The image is assumed to contain a test runner service set up as described in ./BUILD_OS_IMAGE.md
# The image is assumed to contain a test runner service set up as described in ./docs/BUILD_OS_IMAGE.md
cargo run --bin test-manager set debian11 qemu ./os-images/debian11.qcow2 linux \
--package-type deb --architecture x64 \
--artifacts-dir /opt/testing \
Expand Down
232 changes: 146 additions & 86 deletions test/BUILD_OS_IMAGE.md → test/docs/BUILD_OS_IMAGE.md
Original file line number Diff line number Diff line change
@@ -1,46 +1,77 @@
This document explains how to create base OS images and run test runners on them.
# Creating a test image

For macOS, the host machine must be macOS. All other platforms assume that the host is Linux.
This document explains how to create base OS images and run test runners on them.
This guide is written from the perspective of a Linux user, but it should work on Windows as well.

# Configuring a user in the image
## Prerequisites

`test-manager` assumes that a dedicated user named `test` (with password `test`) is configured in any guest system which it should control.
Also, it is strongly recommended that a new image should have passwordless `sudo` set up and `sshd` running on boot,
since this will greatly simplify the bootstrapping of `test-runner` and all needed binary artifacts (MullvadVPN App, GUI tests ..).
The legacy method of pre-building a test-runner image is detailed [further down in this document](#).
You need to have [QEMU](https://www.qemu.org/) installed.

# Creating a base Linux image
# Linux

These instructions use Debian, but the process is pretty much the same for any other distribution.

## Creating a virtual machine

On the host, start by creating a disk image and installing Debian on it:

```
wget https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso
mkdir -p os-images
qemu-img create -f qcow2 ./os-images/debian.qcow2 5G
qemu-system-x86_64 -cpu host -accel kvm -m 4096 -smp 2 -cdrom debian-11.5.0-amd64-netinst.iso -drive file=./os-images/debian.qcow2
wget -O debian.iso https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.5.0-amd64-netinst.iso
qemu-img create -f qcow2 ./debian.qcow2 5G
qemu-system-x86_64 -cpu host -accel kvm -m 4096 -smp 2 -cdrom debian.iso -drive file=./debian.qcow2
```

## Dependencies to install in the image
## Installing Linux

`xvfb` must be installed on the guest system. You will also need
`wireguard-tools` and some additional libraries. They are likely already
installed if gnome is installed.
Follow the distribution's installation process. The only important detail is to set up the [user](#User) correctly.

### Debian/Ubuntu
### User

The testframework expects there to be a regular user in the guest which it can login as.
The `test-manager` makes no assumptions about the login credentials of this user, but they have to be provided as outlined in the [test-manager configuration specification](../test-manager/docs/config.md).

To better illustrate the remaining steps of the installation process, we assume that a regular system user called `test` has been created.

#### sudo

The user should be able to execute `sudo` without a password.

One way of accomplishing this is to add the `test` user to the `wheel` group
```bash
apt install libnss3 libgbm1 libasound2 libatk1.0-0 libatk-bridge2.0-0 libcups2 libgtk-3-0 wireguard-tools xvfb
gpasswd -a test wheel
```

### Fedora
and edit `/etc/sudoers` to allow members of `wheel` to execute commands without a password
```bash
sudo visudo
```

Then comment out
```bash
## Allows people in group wheel to run all commands
# %wheel ALL=(ALL) ALL
```

and add
```bash
## Same thing without a password
%wheel ALL=(ALL) NOPASSWD: ALL
```

#### ssh

Make sure that `sshd.service` is enabled on boot.
```bash
dnf install libnss3 libgbm1 libasound2 libatk1.0-0 libatk-bridge2.0-0 libcups2 libgtk-3-0 wireguard-tools xorg-x11-server-Xvfb
systemctl enable sshd.service
```

# Creating a base Windows image
## Finishing setup

Now you are done! If the VM was configured correctly, `test-manager` will be able to install the required dependencies and run the test suite using the new OS image.
Now you should [add your new VM to the test-manager config](./test-manager/README.md#configuring-test-manager)


# Windows

## Windows 10

Expand All @@ -54,8 +85,6 @@ dnf install libnss3 libgbm1 libasound2 libatk1.0-0 libatk-bridge2.0-0 libcups2 l
qemu-system-x86_64 -cpu host -accel kvm -m 4096 -smp 2 -cdrom <YOUR ISO HERE> -drive file=./os-images/windows10.qcow2
```
(For Windows 11, see the notes below.)
## Windows 11
* Download an ISO: https://www.microsoft.com/software-download/windows11
Expand Down Expand Up @@ -110,7 +139,99 @@ do the following:
1. Press shift-F10 to open a command prompt.
1. Type `oobe\BypassNRO` and press enter.
# Creating a testrunner image (Legacy method)
### Bootstrapping the test runner
The test runner needs to be started on boot, with the test runner image mounted at `E:`.
This can be achieved as follows:
* Restart the VM:
```
qemu-system-x86_64 -cpu host -accel kvm -m 4096 -smp 2 -drive file="./os-images/windows10.qcow2"
```
* In the guest admin `cmd`, add the test runner as a scheduled task:
```
schtasks /create /tn "Mullvad Test Runner" /sc onlogon /tr "\"E:\test-runner.exe\" \\.\COM1 serve" /rl highest
```
Further changes might be required to prevent the task from stopping unexpectedly. In the
Task Scheduler (`taskschd.msc`), change the following settings for the runner task:
* Disable "Start the task only if the computer is on AC power".
* Disable "Stop task if it runs longer than ...".
* Enable "Run task as soon as possible after a scheduled start is missed".
* Enable "If the task fails, restart every: 1 minute".
* In the guest, disable Windows Update.
* Open `services.msc`.
* Open the properties for `Windows Update`.
* Set "Startup type" to "Disabled". Also, click "stop".
* In the guest, disable SmartScreen.
* Go to "Reputation-based protection settings" under
Start > Settings > Update & Security > Windows Security > App & browser control.
* Set "Check apps and files" to off.
* (Windows 11) In the guest, disable Smart App Control
* Go to "Smart App Control" under
Start > Settings > Privacy & security > Windows Security > App & browser control.
* Set it to off.
* Enable autologon by creating or editing the following registry values (all of type REG_SZ):
* Set the current user in
`HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName`.
* Set the password in
`HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword`.
* Set `HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon` to 1.
* Shut down.
## Finishing setup
Now you are done! If the VM was configured correctly, `test-manager` will be able to run the test suite using the new OS image.
Now you should [add your new VM to the test-manager config](./test-manager/README.md#configuring-test-manager)
# macOS 🚧
_Instructions for building an OS image based on macOS are still under construction._
# Legacy methods
The following instructions are either completely deprecated or needed very seldom. We keep these for future reference.
# Linux
## Test runner dependencies
`xvfb` and `wireguard-tools` must be installed on the guest system.
You will also need some additional libraries, but these are most likely already installed if `gnome` is installed.
### Debian/Ubuntu
```bash
apt install wireguard-tools xvfb libnss3 libgbm1 libasound2 libatk1.0-0 libatk-bridge2.0-0 libcups2 libgtk-3-0
```

### Fedora

```bash
dnf install wireguard-tools xorg-x11-server-Xvfb nss mesa-libgbm atk alsa-lib-devel at-spi2-atk gtk3
```

## Creating a test runner image (Legacy method)

The [build-runner-image.sh](./scripts/build-runner-image.sh) script produces a
virtual disk containing the test runner binaries, which must be mounted when
Expand All @@ -121,8 +242,6 @@ you want to build a testrunner-image for.

## Bootstrapping test runner (Legacy method)

### Linux
The testing image needs to be mounted to `/opt/testing`, and the test runner needs to be started on
boot.

Expand Down Expand Up @@ -153,7 +272,7 @@ boot.
### Note about SELinux (Fedora)
SELinux prevents services from executing files that do not have the `bin_t` attribute set. Building
the test runner image stripts extended file attributes, and `e2tools` does not yet support setting
the test runner image strips extended file attributes, and `e2tools` does not yet support setting
these. As a workaround, we currently need to reapply these on each boot.
First, set `bin_t` for all files in `/opt/testing`:
Expand All @@ -176,62 +295,3 @@ ExecStart=/opt/testing/test-runner /dev/ttyS0 serve
[Install]
WantedBy=multi-user.target
```
### Windows
The test runner needs to be started on boot, with the test runner image mounted at `E:`.
This can be achieved as follows:
* Restart the VM:
```
qemu-system-x86_64 -cpu host -accel kvm -m 4096 -smp 2 -drive file="./os-images/windows10.qcow2"
```
* In the guest admin `cmd`, add the test runner as a scheduled task:
```
schtasks /create /tn "Mullvad Test Runner" /sc onlogon /tr "\"E:\test-runner.exe\" \\.\COM1 serve" /rl highest
```
Further changes might be required to prevent the task from stopping unexpectedly. In the
Task Scheduler (`taskschd.msc`), change the following settings for the runner task:
* Disable "Start the task only if the computer is on AC power".
* Disable "Stop task if it runs longer than ...".
* Enable "Run task as soon as possible after a scheduled start is missed".
* Enable "If the task fails, restart every: 1 minute".
* In the guest, disable Windows Update.
* Open `services.msc`.
* Open the properties for `Windows Update`.
* Set "Startup type" to "Disabled". Also, click "stop".
* In the guest, disable SmartScreen.
* Go to "Reputation-based protection settings" under
Start > Settings > Update & Security > Windows Security > App & browser control.
* Set "Check apps and files" to off.
* (Windows 11) In the guest, disable Smart App Control
* Go to "Smart App Control" under
Start > Settings > Privacy & security > Windows Security > App & browser control.
* Set it to off.
* Enable autologon by creating or editing the following registry values (all of type REG_SZ):
* Set the current user in
`HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName`.
* Set the password in
`HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword`.
* Set `HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon` to 1.
* Shut down.
14 changes: 14 additions & 0 deletions test/docs/GITHUB_ACTIONS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
# `test-manager` in Github Actions

There exists a Workflow for running `test-manager` on a selection of different
platforms. The Workflow file can be found
[here](https://github.com/mullvad/mullvadvpn-app/blob/main/.github/workflows/desktop-e2e.yml).

## Adding a new platform

Basically everything related to adding a new virtual machine (VM) to the Workflow is a manual process, but it is fairly straightforward. Most steps (1-3) are performed outside of git, on both your local machine (1) as well as the GitHub runner (2-3). The last step (4) warrants a pull request, as it will make change(s) to the Workflow file.

1. Create a new VM based on [these instructions](./BUILD_OS_IMAGE.md)
2. Upload the newly-assembled VM to the GitHub Actions runner
3. Add an entry for the VM in the [test-manager config file](../test-manager/docs/config.md) on the GitHub runner
4. Update [this Workflow](https://github.com/mullvad/mullvadvpn-app/blob/main/.github/workflows/desktop-e2e.yml) in the [Mullvad App repository](https://github.com/mullvad/mullvadvpn-app/). This will enable GitHub Actions to trigger the `test-manager` with the new VM!
6 changes: 6 additions & 0 deletions test/test-manager/README.me → test/test-manager/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -45,3 +45,9 @@ Error>`
// Run a UI test. Panic if any assertion in it fails!
test_manager::tests::ui::run_test(&rpc, &["gui-test.spec"]).await.unwrap()
```

# Configuring `test-manager`

`test-manager` uses a configuration file to keep track of available virtual machines it can use for testing purposes.

More details can be found in [this configuration format document](./docs/config.md).
Loading

0 comments on commit 3fc2cb8

Please sign in to comment.