acceptance_tests

Last updated: 2025-06-27 01:06:16.357093 File source: link on GitLab

Acceptance tests architecture

Introduction

This document aims to consolidate the architecture supporting the acceptance tests. This architecture can be seen as a revised and simplified architecture of the now phased out Feature Environment.

The decisions supporting this new architecture can be found in the Acceptance Tests ADR

Architecture

The acceptance tests are executed from the repository of the target project to be tested. The pipeline executes make run-acceptance which executes the tests. The actual implementation of the tests may vary with time, but currently these tests are composed by gherkin features just as before with the feature environment, but it uses godog as the framework to implement the feature steps.

topology

The tests are responsible for deploying and managing the virtual machines and the network. They interact with these virtual machines using the incus exec interface provided by the incus sdk for golang.

Infrastructure

The incus server is hosted under test.nunet.io. The server is a baremetal server managed by Hetzner.

The configuration of the server is as dry as possible:

• Ubuntu 24.04

• ubuntu user:

  • passwordless sudo

  • incus-admin group

• Incus installed with apt install incus incus-tools qemu-system

• Configured with unpriviledged containers

Authentication

The authentication between the test execution and the incus servers are done via TLS certificates. A configuration file with the following structure is encoded as base64 and written to DMS_ACC_TEST_CONFIG_B64, which is a CI/CD variable that belongs to the Nunet group:

incus_hosts:
  - host: 10.0.0.0
    port: 8443
    client_cert: |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----
    client_key: |
      -----BEGIN EC PRIVATE KEY-----
      ...
      -----END EC PRIVATE KEY-----
    server_cert: |
      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----

To generate these certificates, a token must first be created with incus config trust add. The token should then be used in a docker container, so that it generates a new client certificate. incus remote add hetzner-test test.nunet.io:8443 --token ${TOKEN} generates the required certificates.

Once that is done, inside the container the certificates are deployed into ~/.config/incus. Client cert and client key reside in ~/.config/incus/client.crt and ~/.config/incus/client.key respectively. The server cert can be found in ~/.config/incus/servercerts/hetzner-test.crt.

Copy the contents of these files into their respective fields in the yaml config file.

A convenience tool hosted under infrastructure/acc-tests-config-maker can be used to generate these configuration files from pre-existing client and server certificates.