Trento Installation Automation

Automated testing infrastructure for Trento release candidate artifacts. This tool is used to provision Azure VMs and install Trento using the official Ansible collection to validate RPM packages before release on supported versions of SUSE SLES for SAP.

Overview

The workflow:

Provision Azure VMs (control and target nodes) using Terraform
Register SUSE machines and activates required modules
Configure package sources from Azure Blob Storage or the Trento rolling repository from OBS
Set up local RPM repositories on target machines when using packages from Azure Blob Storage
Install the Trento Ansible collection on control machines
Configure HTTPS certificates signed by a test certificate authority
Run the suse.trento.site Ansible playbook to install Trento & Trento agent (Agents are installed on same machine as Trento server).
Verify Healthcheck endpoints in every Trento instance from the runner
Run Cypress end-to-end tests against every target node

Infrastructure

The infrastructure consists of paired VMs for each supported SLES version:

Control nodes (control*): Run Ansible playbooks to install Trento on their paired target node
Target nodes (target*): Where Trento server gets installed

VM naming convention: {control|target}{slesVersion}sp{spVersion}

Example: control15sp6 and target15sp6 for SLES 15 SP6.

Prerequisites

Azure Blob Storage Structure

The RPMs under validation are only reachable from the internal network, so they are downloaded and uploaded to Azure Blob Storage manually, over VPN. There is no automated upload step: the workflow assumes the container is already in the desired state when it starts.

RPMs must be uploaded to Azure Blob Storage with the following structure:

<container>/
├── 15/
│   ├── 4/
│   │   ├── trento-web-*.rpm
│   │   ├── trento-wanda-*.rpm
│   │   ├── trento-checks-*.rpm
│   │   ├── trento-agent-*.rpm
│   │   └── ansible-trento-*.rpm
│   ├── 5/
│   │   └── ...
│   └── 6/
│       └── ...
└── 16/
    └── 0/
        └── ...

The directory structure follows the pattern: <sles_major_version>/<sp_version>/

Each version directory should contain:

trento-web-*.rpm - Trento web server
trento-wanda-*.rpm - Trento checks engine
trento-checks-*.rpm - Trento checks catalog
trento-agent-*.rpm - Trento agent
ansible-trento-*.rpm - Ansible collection for Trento installation

When install_rolling is disabled, packages available in Azure Blob Storage are configured with the highest repository priority, and any package missing from it is installed from the official SUSE release sources instead. See Choosing which packages to test for how to use this to validate a partial release. When install_rolling is enabled, the Trento rolling repository from OBS is configured with the highest repository priority and Azure Blob Storage is skipped.

GitHub Configuration

Secrets

Secret Description

Secret	Description
`AZURE_CREDENTIALS`	Azure service principal credentials (JSON)
`PRIVATE_SSH_KEY_CONTENT`	SSH private key for VM access
`AZURE_BLOB_STORAGE_SAS_TOKEN`	SAS token for blob storage access
`SUSE_REGISTRATION_CODE`	SUSE subscription registration code
`SUSE_REGISTRATION_EMAIL`	SUSE subscription email
`WEB_ADMIN_PASSWORD`	Trento web admin password
`TRENTO_TEST_CA_KEY`	Private key of the test certificate authority used to sign Trento HTTPS certificates

AZURE_CREDENTIALS

Azure service principal credentials (JSON)

PRIVATE_SSH_KEY_CONTENT

SSH private key for VM access

AZURE_BLOB_STORAGE_SAS_TOKEN

SAS token for blob storage access

SUSE_REGISTRATION_CODE

SUSE subscription registration code

SUSE_REGISTRATION_EMAIL

SUSE subscription email

WEB_ADMIN_PASSWORD

Trento web admin password

TRENTO_TEST_CA_KEY

Private key of the test certificate authority used to sign Trento HTTPS certificates

Test certificate authority

TRENTO_TEST_CA_CRT and TRENTO_TEST_CA_KEY must belong to the same test certificate authority. The workflow uses them to sign the HTTPS certificates configured in the Trento reverse proxy, and the runner trusts TRENTO_TEST_CA_CRT before running health checks and Cypress tests.

TRENTO_TEST_CA_CRT is public and should be stored as a GitHub Actions variable. It can be imported locally by developers who need to access the generated Trento environments from a browser. TRENTO_TEST_CA_KEY is sensitive and should only be stored in GitHub Actions secrets and the team’s password vault.

Variables

Variable Description

Variable	Description
`AZURE_RESOURCE_GROUP`	Azure resource group name
`AZURE_OWNER_TAG`	Owner tag for Azure resources
`AZURE_BLOB_STORAGE`	Storage account name
`AZURE_BLOB_STORAGE_CONTAINER`	Container with RPMs
`AZURE_BLOB_STORAGE_TF_STATE_CONTAINER`	Container for Terraform state
`PUBLIC_SSH_KEY_CONTENT`	SSH public key for VM access
`TRENTO_TEST_CA_CRT`	Public certificate of the test certificate authority used to sign Trento HTTPS certificates

AZURE_RESOURCE_GROUP

Azure resource group name

AZURE_OWNER_TAG

Owner tag for Azure resources

AZURE_BLOB_STORAGE

Storage account name

AZURE_BLOB_STORAGE_CONTAINER

Container with RPMs

AZURE_BLOB_STORAGE_TF_STATE_CONTAINER

Container for Terraform state

PUBLIC_SSH_KEY_CONTENT

SSH public key for VM access

TRENTO_TEST_CA_CRT

Public certificate of the test certificate authority used to sign Trento HTTPS certificates

Supported OS Versions

15.4
15.5
15.6
15.7
16.0

Each entry creates a control and target VM pair for that SLES version. The format is {major}.{sp}, for example 15.6 for SLES 15 SP6 and 16.0 for SLES 16.

The manual workflows expose one boolean input per supported version so you can choose the target OS versions directly when launching the workflow.

Usage

Running Tests

Go to Actions > Trento Installation Tests
Click Run workflow
Select the SLES versions you want to deploy to
Optionally enable install_rolling to install packages from the Trento rolling repository from OBS instead of Azure Blob Storage
Optionally enable skip_cypress to stop after deployment and health verification
Click Run workflow

The workflow always recreates the Terraform-managed infrastructure before installing Trento. After installation, Cypress end-to-end tests run against each target node unless skip_cypress is enabled. If Cypress fails, screenshots are uploaded as workflow artifacts.

Two behaviors are worth knowing before launching a run:

Manually dispatched runs do not destroy the infrastructure when they finish, so the deployed environments stay available for manual inspection. Destroy them with the Azure Cleanup workflow once you are done.
All runs share the trento-installation-tests concurrency group and are never canceled, so a run started while another one is in progress waits in the queue instead of starting immediately.

Choosing which packages to test

Packages present in Azure Blob Storage are installed with the highest repository priority, and every package missing from it is installed from the official SUSE release sources. This is what makes it possible to validate a partial release, for example a release candidate where only trento-web is published.

The storage account and container to upload to are configured in the AZURE_BLOB_STORAGE and AZURE_BLOB_STORAGE_CONTAINER repository variables.

Before launching the workflow, connect to the VPN and, for each SLES version you plan to deploy to, perform the following steps:

Delete the RPMs left in <container>/<sles_major_version>/<sp_version>/ by previous runs.
Upload only the RPMs under validation.

Deleting the leftover RPMs is mandatory. The blob-backed repository is configured with priority 1, which zypper prefers over the official repositories even if they offer a newer version. An RPM left over from a previous run is repeatedly installed until it is removed from the container.

For example, to validate a trento-web release candidate on SLES 15 SP6, leave only trento-web-*.rpm in the 15/6/ directory. The remaining packages, trento-wanda, trento-checks, trento-agent and ansible-trento, are then installed from the official SUSE release sources.

Packages are split between the two node types:

Target nodes get every RPM except ansible-trento-*.rpm served from a local repository built from the container contents.
Control nodes get only ansible-trento-*.rpm installed directly from the downloaded file. When the container provides no ansible-trento RPM, the package is installed from the official SUSE release sources.

If the version directory is missing or contains no RPMs, every package is installed from the official SUSE release sources. Enabling install_rolling ignores Azure Blob Storage entirely and installs everything from the Trento rolling repository.

SLES 15 SP4 and the Ansible collection

ansible-trento is not officially released for SLES 15 SP4, so release candidate artifacts never include an SP4 build of it. Trento can still be installed on an SP4 target, because the SP4 control node does not use the distribution Ansible. Instead, it creates a Python virtual environment and installs ansible 9 with pip, and configures it to use the collection provided by the RPM. The collection therefore works regardless of which service pack it was built for.

When preparing a run that includes SP4, upload the SP5 ansible-trento release candidate to the 15/4/ directory alongside the rest of the SP4 packages.

This workaround only exists while SLES 15 SP4 is supported, and can be removed once support ends at the end of 2026.

Accessing the deployed environments

Because manually dispatched runs leave the infrastructure in place, each target node stays reachable for manual validation at https://target<sles_version>sp<sp_version>.<azure_region>.cloudapp.azure.com/, where <azure_region> is the location of AZURE_RESOURCE_GROUP. For example, https://target15sp7.westeurope.cloudapp.azure.com/ for SLES 15 SP7. Control nodes follow the same pattern with the control prefix.

You can access the deployments using the following methods:

Browser: Import TRENTO_TEST_CA_CRT into your browser or system trust store, otherwise the HTTPS certificate is rejected. Log in with the admin user and the password stored in WEB_ADMIN_PASSWORD.
SSH: Connect as cloudadmin with the private key matching PUBLIC_SSH_KEY_CONTENT.

The SSH key pair, the test certificate authority and the Trento admin password are all available in the team’s password vault.

Continuous Integration

The Continuous Integration workflow runs on pushes to main, pull request open/update events, and manual dispatches. Changes that only touch **.adoc files or LICENSE do not trigger it, since they cannot affect a deployment. It calls the reusable installation base workflow with all supported SLES versions enabled, installs packages from the Trento rolling repository, runs only the **/about.cy.js Cypress spec against every target node, and destroys the Terraform-managed infrastructure after completion.

Cleanup

To destroy all provisioned infrastructure:

Go to Actions > Azure Cleanup
Click Run workflow

The cleanup workflow always generates the full machine configuration for every supported SLES version before running terraform destroy, so manual cleanup and CI cleanup both target all Terraform-managed infrastructure by default.

Supported SLES Versions

SLES 15 SP4
SLES 15 SP5
SLES 15 SP6
SLES 15 SP7
SLES 16

License

See LICENSE file.