LogoLogo
WebsiteTechnical Discussions
Developer documentation
Developer documentation
  • Public Technical Documentation
    • device-management-service
      • main
        • actor
        • api
        • cmd
          • actor
          • cap
        • db
          • clover
          • repositories
        • dms
          • behaviors
          • jobs
          • node
          • onboarding
          • resources
        • docs
          • deployments
          • onboarding
          • private_network
        • executor
          • docker
          • firecracker
          • background_tasks
          • config
          • hardware
        • maint-scripts
        • network
          • libp2p
        • observability
        • specs
          • basic_controller
          • s3
          • volume
          • e2e
        • tokenomics
        • types
        • utils
          • validate
      • release
        • actor
        • api
        • cmd
          • actor
          • cap
        • db
          • repositories
            • clover
        • dms
          • behaviors
          • hardware
          • jobs
          • node
          • onboarding
          • resources
        • docs
          • deployments
          • onboarding
          • private_network
        • executor
          • docker
          • firecracker
        • internal
          • background_tasks
          • config
        • maint-scripts
        • network
          • libp2p
        • observability
        • plugins
        • specs
        • storage
          • basic_controller
          • s3
          • volume
        • test
        • tokenomics
        • types
        • utils
          • validate
    • solutions
      • asi-node
        • main
          • demos
            • ocap_auth
              • ansible
              • videos
          • did-auth-use-scenarios
            • create-a-hosting-deployment
            • make-a-payment
            • manage-dids-and-ocaps
            • register-an-ai-agent
            • submit-a-compute-job
          • pilots
            • asi-create-authentication-poc
        • release
      • nunet-appliance
        • main
        • release
    • test-suite
      • main
        • cicd
          • tests
            • acceptance_tests
            • feature_environment
          • cli
          • dms-on-lxd
            • local
        • environments
          • development
          • feature
          • production
          • staging
        • infrastructure
          • acc-tests-config-maker
          • cloud-init
          • nginx
        • stages
          • dependency_scanning
          • functional_tests
          • integration_tests
          • load_tests
          • regression_tests
          • security_tests_1
          • security_tests_2
          • security_tests_live
          • unit_tests
          • user_acceptance_tests
      • release
        • cicd
          • tests
            • acceptance_tests
            • feature_environment
          • cli
          • dms-on-lxd
            • local
        • environments
          • development
          • feature
          • production
          • staging
        • infrastructure
          • acc-tests-config-maker
          • cloud-init
          • nginx
        • stages
          • dependency_scanning
          • functional_tests
          • integration_tests
          • load_tests
          • regression_tests
          • security_tests_1
          • security_tests_2
          • security_tests_live
          • unit_tests
          • user_acceptance_tests
    • team-processes-and-guidelines
      • main
        • best_practices
        • ci_cd_pipeline
        • community_feedback_process
        • contributing_guidelines
        • git_workflows
        • nunet_test_process_and_environments
        • secure_coding_guidelines
        • specification_and_documentation
        • team_process
          • a_project_management
          • b_ceremonies_artifacts
          • c_drum_buffer_rope
          • d_development_process
          • e_culture_rules
          • f_mr_review
        • vulnerability_management
          • devsecops_maturity_models
          • nunet_security_pipeline
          • secret_management
          • sop_security_mr_review
Powered by GitBook
On this page
  • Acceptance tests architecture
  • Introduction
  • Architecture
  • Infrastructure
Export as PDF
  1. Public Technical Documentation
  2. test-suite
  3. release
  4. cicd
  5. tests

acceptance_tests

PrevioustestsNextfeature_environment

Last updated 14 hours ago

Last updated: 2025-06-06 01:06:50.475680 File source:

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 .

The decisions supporting this new architecture can be found in the

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

Authentication

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.

Configured with

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 :

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

unpriviledged containers
Nunet group
convenience tool
link on GitLab
Feature Environment
Acceptance Tests ADR
godog