Install Allure TestOps via RPM packages
This section describes how to install Allure TestOps 5.x on CentOS or RedHat Enterprise Linux using RPM packages.
For reference, we kept the outdated installation manual for version 4.
Depending on the operating system's settings, you may encounter issues when pasting multi-line commands from this page into the terminal. To fix the behavior, we recommend running this command before you begin:
bind 'set enable-bracketed-paste on'
Migration from version 4
Allure TestOps version 5 cannot be deployed above the version 4. The upgrade process requires the data migration and switching to the new configuration.
The upgrade is possible only from the release 4.26.5. Using older releases for the upgrade process will brick the system and will lead to the data loss.
The upgrade to version 5 requires the following steps:
- Create the new
testops.conf
file for the updated RPM package based on your current configuration. - Stop the existing instance.
- Merge the information from the UAA service database to the report service database.
- Start the deployment using the RPM package.
For more detailed information on upgrading your version of Allure TestOps to 5.x, follow the migration guide.
Preparation steps
Make sure you run one of the following operating systems:
- CentOS 8 or newer,
- RedHat Enterprise Linux 8 or newer.
To check the version of your operating system, run this in terminal:
source /etc/os-release; echo $PRETTY_NAME
Do not install Allure TestOps on a machine that is used for other purposes. Allure TestOps demands a lot of resources, so sharing resources with other software can cause serious performance issues.
Also, you must not perform bulk software updates on this machine using
yum update
.Deploy additional services:
- PostgreSQL database,
- MinIO or other S3-compatible storage server,
- RabbitMQ message server,
- Redis storage server.
Note that it is recommended to run PostgreSQL and S3-compatible storage on separate machines. See Storage requirements for more details.
Get a license for Allure TestOps.
To receive the license key, contact us at [email protected] for a commercial license. Please indicate that you are planning to install Allure TestOps via RPM packages.
When you receive the license key, you will also get a username and a password for accessing Qameta's RPM repository.
Get details for configuring authentication.
The required details depend on which approach to user authentication you choose. There are two possible approaches.
Standard password-based authentication, implemented by Allure TestOps itself.
This option uses an SMTP server to send invitations to new users and does not require additional services.
Authentication via an external identity provider.
The details required for this may vary depending on what type of identity provider you use. Usually, you will need to specify an external URL and a secret token generated by the identity provider.
See Configuration → Authentication for more details.
Installing dependencies
Amazon Corretto
Amazon Corretto version 21 is used as the JDK implementation for running Allure TestOps. To install it, run the following commands in a terminal:
wget -q -O- https://yum.corretto.aws/corretto.repo | sudo tee /etc/yum.repos.d/corretto.repo
sudo yum install -y java-21-amazon-corretto-devel
For more details, see the installation guide on the Amazon website.
PostgreSQL
While not recommended for high-load use cases, it is possible to run PostgreSQL on the same machine you will be running Allure TestOps on. To install it, run the following commands in a terminal:
sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-$(rpm -E %{rhel})-$(arch)/pgdg-redhat-repo-latest.noarch.rpm
sudo dnf -y module disable postgresql
sudo yum install -y postgresql15-server
sudo /usr/pgsql-15/bin/postgresql-15-setup initdb
sudo systemctl enable postgresql-15
sudo systemctl start postgresql-15
For more details, see the installation guide on the PostgreSQL website.
Wherever the PostgreSQL server is deployed, make sure to log into that server and prepare the database for Allure TestOps.
RabbitMQ
To install RabbitMQ, run the following commands in the terminal:
wget -q -O- https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-erlang/setup.rpm.sh | sudo bash
sudo yum install -y socat logrotate initscripts erlang
sudo yum install -y https://github.com/rabbitmq/rabbitmq-server/releases/download/v3.13.2/rabbitmq-server-3.13.2-1.el8.noarch.rpm
sudo chkconfig rabbitmq-server on
sudo /sbin/service rabbitmq-server start
For more details, see the installation guide on the RabbitMQ website.
Redis
To install Redis, run the following command in the terminal:
sudo yum install -y redis
Installing Allure TestOps
Allure TestOps packages are distributed via a repository that requires authentication. If you have a trial or commercial license for Allure TestOps, you should have received the username and password in the same email where you got the license key. If you cannot find it, contact us at [email protected].
Once you have got the login and password, do the following.
Add the Qameta repository to your system.
Note that you must paste this command as a whole, without running its lines separately. Before executing the command, replace “USERNAME” and “PASSWORD” with the credentials provided to you by the Qameta sales team.
cat <<EOF | sudo tee /etc/yum.repos.d/qameta.repo [Qameta] name=Qameta baseurl=https://dl.qameta.io/artifactory/rhel/ enabled=1 gpgcheck=0 username=USERNAME password=PASSWORD EOF
Install the Allure TestOps package.
Before executing the command, replace
5.7.0
with the version you want to use.sudo yum install -y testops-5.7.0
Check out the Release notes section for the list of available versions. In general, it is recommended to use the latest release.
Make sure that incoming traffic to the TCP port 8080 is allowed.
This step may be done in different ways, depending on the firewall you use. Here's an example for the default CentOS setup:
sudo firewall-cmd --permanent --add-port=8080/tcp sudo firewall-cmd --reload
Editing the configuration file
The configuration parameters are defined in the /opt/testops/conf/testops.conf configuration file.
To change the parameters, open the file in a text editor, modify the values you need and save it. After that, restart Allure TestOps to apply the changes.
You need to use superuser privileges to modify the configuration file. One way to edit it with such privileges is to use the
sudo nano
command in a terminal:sudo nano /opt/testops/conf/testops.conf
For the most typical setup, just do the following:
- Set TestOps URL.
- Set encryption key for sensitive data.
- Set first admin email.
- Configure authentication.
- Configure storage services.
Set TestOps URL
In the ALLURE_ENDPOINT
parameter, specify the URL which should be used to access the Allure TestOps web interface.
ALLURE_ENDPOINT=https://testops.example.com/
To make Allure TestOps available via HTTPS, you need to configure a reverse proxy. See Network configuration for more details.
If you plan to integrate Allure TestOps with Jira, you need to use HTTPS and enable secure cookies, otherwise the integration will not work correctly. See Integration with Jira Data Center and Integration with Jira Software Cloud for more details.
ALLURE_SECURE=true
Set encryption key for sensitive data
As a security measure, Allure TestOps encrypts the sensitive values in its database using AES256 algorithm. This way, if a malicious actor gets access to the PostgreSQL database but not to the configuration file, this will not compromise the other services' credentials used by the deployment.
AES256 requires usage of an encryption key. To set the encryption key, update the value of the ALLURE_CRYPTO_PASSWORD
parameter and keep it in a safe place.
Note that if the value is lost or changed after the initial deployment, all previously configured integrations will stop working. In such a case, you will need to go to each projects' settings and re-enter valid credentials.
ALLURE_CRYPTO_PASSWORD=ogheRiy7ooCh6Oocei6OdaD1iequooNa
Set first admin email
Starting from the version 5.4.0, valid SMTP credentials are required in any configuration. Allure TestOps will use them for sending an invitation email to the administrator, regardless of the main authentication method. The administrator's email address must be specified in the ALLURE_MAIL_ROOT
parameter.
Below is an example of configuration parameters for a Gmail account. Note that Google requires to generate app passwords for SMTP. Other mail services may have similar requirements.
SPRING_MAIL_HOST=smtp.gmail.com
SPRING_MAIL_PORT=465
[email protected]
SPRING_MAIL_PASSWORD=Ohku6Zo9gee5aen0
[email protected]
SPRING_MAIL_PROPERTIES_MAIL_SMTP_AUTH=true
SPRING_MAIL_PROPERTIES_MAIL_SMTP_STARTTLS_ENABLE=true
SPRING_MAIL_PROPERTIES_MAIL_SMTP_STARTTLS_REQUIRED=true
SPRING_MAIL_PROPERTIES_MAIL_SMTP_SSL_ENABLE=true
SPRING_MAIL_PROPERTIES_MAIL_SMTP_SSL_TRUST=smtp.gmail.com
#...
[email protected]
Configure authentication
A necessary step when deploying Allure TestOps is to configure how users (other than the very first administrator) will be registered and logged in. See Configuration → Authentication for more details.
Below are some configuration examples for various identity providers.
No additional configuration is required. This authentication (system) requires SMTP to be enabled.
#Example of using LDAP
ALLURE_LOGIN_PRIMARY=ldap
ALLURE_LOGIN_LDAP_ENABLED='true'
ALLURE_LOGIN_LDAP_REFERRAL=follow
ALLURE_LOGIN_LDAP_URL=ldap://ldap.url.here:port
#ALLURE_LOGIN_LDAP_USERDNPATTERNS= do not use with ALLURE_LOGIN_LDAP_USERSEARCHFILTER
ALLURE_LOGIN_LDAP_USERSEARCHBASE="ou=People,dc=space"
ALLURE_LOGIN_LDAP_USERSEARCHFILTER="uid={0}"
ALLURE_LOGIN_LDAP_DEFAULTROLE=${LDAP_DEFAULT_ROLE}
ALLURE_LOGIN_LDAP_UIDATTRIBUTE=uid
ALLURE_LOGIN_LDAP_SYNCROLES='true'
#these are to be enabled if ALLURE_LOGIN_LDAP_SYNCROLES='true'
ALLURE_LOGIN_LDAP_GROUPSEARCHBASE="ou=group,dc=space"
ALLURE_LOGIN_LDAP_GROUPSEARCHFILTER="memberUid={1}"
ALLURE_LOGIN_LDAP_GROUPROLEATTRIBUTE=cn
ALLURE_LOGIN_LDAP_GROUPAUTHORITIES_ROLEUSERGROUPS=group_with_ato_users,every_user_is_user
ALLURE_LOGIN_LDAP_GROUPAUTHORITIES_ROLEADMINGROUPS=group_with_ato_admins,every_user_is_admin
#service account data to log-in to LDAP
ALLURE_LOGIN_LDAP_USERDN="cn=admin,dc=space"
ALLURE_LOGIN_LDAP_PASSWORD='ServiceAccountPasswordHere'
#additional parameters, can be disabled by default
#ALLURE_LOGIN_LDAP_LOWERCASEUSERNAMES=true
#ALLURE_LOGIN_LDAP_PASSWORDATTRIBUTE=userPassword
To use OpenID IdP you need to add the following parameters to the configuration and fill these with appropriate data.
# OpenId settings
# The text ID for the SSO provider. Will be used in URLs and displayed on the login buttons.
# Don't use whitespaces and special characters
# You can use array of different providers using different oauth2:
# SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_<PROVIDER_NAME>_... + SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_<PROVIDER_NAME>_...
########################################################################################
TESTOPS_OPENID_CLIENTNAME - the text id of the OpenID client (TestOps is the OpenID client)
TESTOPS_OPENID_CLIENTID - The identifier of Allure TestOps as client in OpenID provider
TESTOPS_OPENID_CLIENTSECRET - secret generated at OpenID providert to authenticate the client application
TESTOPS_OPENID_REDIRECTURI - the URL ro which OpenId provider must redirect successfully authenticated end user
TESTOPS_OPENID_AUTHORIZATIONURI - the URI, to which TestOps instance must forward the end user for the authentication
TESTOPS_OPENID_USERINFOURI - It is advertised in the server metadata
TESTOPS_OPENID_ISSUERURI - It is advertised in the server metadata
TESTOPS_OPENID_CLIENTNAME=TestOps
TESTOPS_OPENID_CLIENTID=<YOUR_CLIENT_ID>
TESTOPS_OPENID_CLIENTSECRET=<YOUR_CLIENT_SECRET_HERE>
TESTOPS_OPENID_REDIRECTURI=https://<your-domain>/login/oauth2/code/openid
TESTOPS_OPENID_SCOPE=openid,email,profile
TESTOPS_OPENID_AUTHORIZATIONURI=http://<open_id_provider_url>/realms/<you_realm>/protocol/openid-connect/auth
TESTOPS_OPENID_USERINFOURI=http://<open_id_provider_url>/realms/<you_realm>/protocol/openid-connect/userinfo
TESTOPS_OPENID_ISSUERURI=http://<open_id_provider_url>/realms/<you_realm>
TESTOPS_OPENID_USERNAMEATTRIBUTE=preferred_username
TESTOPS_OPENID_DEFAULTROLE=ROLE_GUEST
TESTOPS_OPENID_SYNCROLES - Defines whether TestOps should assign global roles based on the OpenID server group membership
TESTOPS_OPENID_GROUPROLEATTRIBUTE - defines the name of a claim to look for
TESTOPS_OPENID_GROUPAUTHORITIES_ROLEUSERGROUPS - members of these groups will be granted ROLE_USER global role
TESTOPS_OPENID_GROUPAUTHORITIES_ROLEADMINGROUPS - members of these groups will be granted ROLE_ADMIN global role
TESTOPS_OPENID_SYNCROLES=false
TESTOPS_OPENID_GROUPROLEATTRIBUTE=group
TESTOPS_OPENID_GROUPAUTHORITIES_ROLEUSERGROUPS=roleUserGroups
TESTOPS_OPENID_GROUPAUTHORITIES_ROLEADMINGROUPS=roleAdminGroups
Configure storage services
Specify the details for connecting to the storage services required for Allure TestOps.
Connection to the Redis storage server
SPRING_DATA_REDIS_HOST
— server hostname.SPRING_DATA_REDIS_PORT
— server port.SPRING_DATA_REDIS_PASSWORD
— password for connecting to the storage.
Connection to the PostgreSQL databases
SPRING_DATASOURCE_URL
— database location in the JDBC URL format.SPRING_DATASOURCE_USERNAME
— username for connecting to the database.SPRING_DATASOURCE_PASSWORD
— password for connecting to the database.
Connection to the RabbitMQ server
SPRING_RABBITMQ_HOST
— server hostname.SPRING_RABBITMQ_PORT
— server port.SPRING_RABBITMQ_USERNAME
— username for connecting to the message queue.SPRING_RABBITMQ_PASSWORD
— password for connecting to the message queue.
Connection to the S3-compatible storage server
ALLURE_BLOBSTORAGE_S3_ENDPOINT
— server URL.ALLURE_BLOBSTORAGE_S3_BUCKET
— S3 bucket name.ALLURE_BLOBSTORAGE_S3_REGION
— S3 region name.ALLURE_BLOBSTORAGE_S3_ACCESSKEY
— access key for connecting to the bucket.ALLURE_BLOBSTORAGE_S3_SECRETKEY
— secret key for connecting to the bucket.
Some additional settings can be modified to fine-tune the performance or support non-standard configurations of the storage services. Check the comments in the testops.conf file and consult the Qameta support team if necessary.
First start
When you start your Allure TestOps installation for the first time, you need to activate it by providing the license key. You should have received the license key in an email from the Qameta sales team.
Open a terminal application.
Restart the services to apply the changes in the configuration file.
sudo systemctl restart testops
Restarting all the services of Allure TestOps takes some time. Wait for a couple of minutes before proceeding to the next step.
Soon after startup, Allure TestOps will send an invitation email to the address that you specified in
ALLURE_MAIL_ROOT
. Check the inbox and click the Accept invite link in the email.If you get an “Unable to connect” or “This site can't be reached” error in the browser, it may indicate that some services are still initializing. Normally, the initialization takes no more than a couple of minutes.
If the web browser still cannot open the page after five minutes, see the Troubleshooting section.
In the invitation accept form, fill in the administrator's full name and the credentials that will be used in the login form: Username and Password. The Username must be unique within the Allure TestOps instance.
Click Continue.
In the activation form, enter the license key that you got from Qameta sales team. Make sure to paste the key without any extra spaces or other characters.
Click Activate license.
Managing services status
Start services
To start Allure TestOps, open a terminal application and run the command:
sudo systemctl start testops
Stop services
To stop Allure TestOps, open a terminal application and run the command:
sudo systemctl stop testops
Restart services
To restart Allure TestOps, open a terminal application and run the command:
sudo systemctl restart testops
Upgrading
Before you begin, make sure to read the release notes for the Allure TestOps version you are upgrading to. The release notes may contain crucial information on how to adapt your configuration files or migrate your data to the new version of Allure TestOps. In case you are skipping one or more versions, read the release notes for the skipped versions, too.
Open a terminal application.
Refresh the index of available packages.
sudo yum check-update
Reinstall the package.
Before executing the command, replace
5.7.0
with the version you are upgrading to.sudo yum install -y testops-5.7.0
If necessary, modify your configuration files according to the relevant release notes.
Restart Allure TestOps.
sudo systemctl restart testops
Uninstalling
To uninstall the Allure TestOps instance:
Open a terminal application.
Remove the Allure TestOps packages:
sudo yum remove testops-*
Remove your configuration files:
sudo rm -rf /opt/testops
Troubleshooting
If you run into any issues, please check our FAQ page.
Also, in case of any troubles, do not immediately bring Allure TestOps down and up. We need the log files of each component to understand what has happened.
If you encounter an issue not covered in the FAQ, feel free to create a support ticket using your corporate email address. Please include the following information in the ticket:
- Description of the problem you are experiencing.
- Versions of Allure TestOps and all extra components you are having problems with (allurectl, integration plugins, etc.).
- Logs from your system as attachments to the ticket (see the details below). Please only send us the logs described below and only as an attachment.
journalctl -f -n 100 -u testops
where:
- f - to follow the journal, i.e. all the new lines will be shown on the screen
- n 100 - the number of journal entries to show
- u name - name of a unit
Getting logs
By default, all components write logs to stdout. You can get the logs using journalctl:
journalctl --no-tail -u testops > testops.log