### Start Docker Compose Deployment

Source: https://docs.qameta.io/allure-testops/migrations/to-5113

Starts the Allure TestOps services using the updated docker-compose.yml file.

```bash
docker compose up -d

```

--------------------------------

### Start Allure TestOps Services

Source: https://docs.qameta.io/allure-testops/install/docker-compose

Initiates the Allure TestOps application by starting its services using Docker Compose. Ensure you are in the installation directory before running this command. This command runs services in detached mode.

```bash
cd ~/testops
docker compose up -d
```

--------------------------------

### Install RabbitMQ

Source: https://docs.qameta.io/allure-testops/install/deb

Commands to install RabbitMQ, a message broker. This includes fetching the setup script, installing dependencies like erlang, downloading the RabbitMQ server package, and enabling/starting the service. Note: Allure TestOps does not support quorum queues in high-availability mode for RabbitMQ version 4.0 and above.

```bash
wget -q -O- https://dl.cloudsmith.io/public/rabbitmq/rabbitmq-erlang/setup.deb.sh | sudo bash
sudo apt install -y socat logrotate erlang
wget https://github.com/rabbitmq/rabbitmq-server/releases/download/v3.13.2/rabbitmq-server_3.13.2-1_all.deb -O rabbitmq-server.deb
sudo dpkg -i rabbitmq-server.deb
sudo systemctl enable rabbitmq-server
sudo systemctl start rabbitmq-server
```

--------------------------------

### Allure TestOps Service Management - Start

Source: https://docs.qameta.io/allure-testops/install/v4-deb

This command starts all the core Allure TestOps services: gateway, UAA, and report. It requires root privileges and should be executed in a terminal.

```bash
sudo systemctl start allure-gateway allure-uaa allure-report

```

--------------------------------

### Install Allure TestOps (Box Package)

Source: https://docs.qameta.io/allure-testops/install/v4-rpm

Installs the Allure TestOps 'box' package using yum. Replace '4.22.1' with the desired version. This option automatically installs MinIO and Redis locally, assuming PostgreSQL is already installed.

```bash
sudo yum install -y allure-testops-box-4.22.1

```

--------------------------------

### Start Allure TestOps Service (DEB/RPM)

Source: https://docs.qameta.io/allure-testops/migrations/to-5113

Starts the Allure TestOps application after configuration updates when installed via DEB or RPM packages using systemd.

```bash
sudo systemctl start testops

```

--------------------------------

### Launches AQL

Source: https://docs.qameta.io/allure-testops/advanced/aql

Query launches using AQL. Available fields include id, name, tag, issue, job, createdDate, createdBy, lastModifiedDate, and lastModifiedBy.

```APIDOC
## Launches AQL

### Description
Query launches using AQL. Available fields include id, name, tag, issue, job, createdDate, createdBy, lastModifiedDate, and lastModifiedBy.

### Method
GET

### Endpoint
/api/launches

### Parameters
#### Query Parameters
- **aql** (string) - Required - The AQL query string for filtering launches.

### Request Example
```json
{
  "aql": "name = \"release-1.0\" and tag = \"regular\""
}
```

### Response
#### Success Response (200)
- **results** (array) - A list of launches matching the query.
  - **id** (integer) - Launch identifier.
  - **name** (string) - Launch name.
  - **tag** (array) - Launch tags.
  - **issue** (object) - Issues linked to a launch.
  - **job** (string) - Build job name.
  - **createdDate** (integer) - Date when the launch was created.
  - **createdBy** (string) - User who created the launch.
  - **lastModifiedDate** (integer) - Date when the launch was last modified.
  - **lastModifiedBy** (string) - User who last modified the launch.

#### Response Example
```json
{
  "results": [
    {
      "id": 17,
      "name": "release-1.0",
      "tag": ["regular"],
      "issue": {},
      "job": "jenkins_master",
      "createdDate": 1569430502709,
      "createdBy": "user1",
      "lastModifiedDate": 1569430502709,
      "lastModifiedBy": "user1"
    }
  ]
}
```
```

--------------------------------

### Testing LDAP Connection with ldapsearch (Allure Specific Example)

Source: https://docs.qameta.io/allure-testops/configuration/authentication/ldap

This shell command demonstrates testing your Allure TestOps LDAP configuration using `ldapsearch` with Allure-specific environment variables. It shows how to connect and search for a user, with arguments mapping to the `ALLURE_LOGIN_LDAP_` prefixed variables.

```bash
ldapsearch \
    -H '${ALLURE_LOGIN_LDAP_URL}' \
    -D '${ALLURE_LOGIN_LDAP_USERDN}' \
    -w '${ALLURE_LOGIN_LDAP_PASSWORD}' \
    -b '${ALLURE_LOGIN_LDAP_USERSEARCHBASE}' \
    '${ALLURE_LOGIN_LDAP_USERSEARCHFILTER}'

```

--------------------------------

### Download Docker Compose Configuration (Unix-like)

Source: https://docs.qameta.io/allure-testops/migrations/to-5

Downloads the Allure TestOps Docker Compose configuration files using `wget` and unzips them into a 'testops' directory. This command fetches the latest configuration and prepares it for local deployment. Alternatively, manual download is possible.

```bash
wget https://dl.qameta.io/artifactory/bin/docker-compose/testops-docker-compose.zip -O testops-compose.zip && unzip testops-compose.zip -d "testops"
```

--------------------------------

### Create Full Database Dump (PostgreSQL)

Source: https://docs.qameta.io/allure-testops/migrations/to-5

Creates a full SQL dump of a PostgreSQL database. Requires database connection details and credentials. Outputs a .sql file.

```bash
# create the database dump
pg_dump --file=report-dump.sql \
  --host="db.example.com" --port=5432 --username=report --dbname=report

# export the password for the database
export PGPASSWORD='password_of_uaa_db_user_here'
# create the database dump
pg_dump --file=uaa-dump.sql \
  --host="db.example.com" --port=5432 --username=uaa --dbname=uaa
```

--------------------------------

### Configuration Example for Blob Batch Size

Source: https://docs.qameta.io/allure-testops/briefly/project/cleanup

This example shows how to set the `ALLURE_SCHEDULER_CLEANER_BLOB_BATCHSIZE` parameter in Allure TestOps settings. This parameter controls the number of files deleted in each batch, and adjusting it can help manage large cleanup queues.

```yaml
ALLURE_SCHEDULER_CLEANER_BLOB_BATCHSIZE: 2000
```

--------------------------------

### Configure Qameta Repository Credentials

Source: https://docs.qameta.io/allure-testops/install/v4-deb

This command configures authentication for the Qameta repository by echoing credentials and saving them to a configuration file. Replace USERNAME and PASSWORD with your provided credentials.

```bash
echo "machine dl.qameta.io login USERNAME password PASSWORD" | sudo tee /etc/apt/auth.conf.d/qameta.conf

```

--------------------------------

### DEB/RPM SMTP Configuration Example

Source: https://docs.qameta.io/allure-testops/configuration/smtp

Example of SMTP configuration parameters for a Gmail account when using DEB/RPM installation. These settings are typically found in the `/opt/testops/conf/testops.conf` file. Some mail servers require the 'From' address to match the username.

```properties
SPRING_MAIL_HOST=smtp.gmail.com
SPRING_MAIL_PORT=587
SPRING_MAIL_USERNAME=noreply@example.com
SPRING_MAIL_PASSWORD=Ohku6Zo9gee5aen0
ALLURE_MAIL_FROM=noreply@example.com
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

```

--------------------------------

### Stop Allure TestOps Service (DEB/RPM)

Source: https://docs.qameta.io/allure-testops/migrations/to-5113

Stops the Allure TestOps application when installed via DEB or RPM packages using systemd.

```bash
sudo systemctl stop testops

```

--------------------------------

### Testing LDAP Connection with ldapsearch (Kubernetes Example)

Source: https://docs.qameta.io/allure-testops/configuration/authentication/ldap

This shell command demonstrates how to test your Allure TestOps LDAP configuration using the `ldapsearch` utility. It shows how to connect to the LDAP server and search for a user, with arguments mapping directly to Kubernetes configuration parameters.

```bash
ldapsearch \
    -H 'ldap://ldap.example.com:389' \
    -D 'cn=admin,dc=example,dc=com' \
    -w 'SecretPa$$w0rd' \
    -b 'dc=example,dc=com' \
    '(&(objectClass=person)(uid=john))'

```

--------------------------------

### Allure TestOps UAA Configuration - LDAP Example

Source: https://docs.qameta.io/allure-testops/install/v4-deb

This snippet provides an example configuration for integrating Allure UAA with an LDAP server for authentication. It covers LDAP connection details, user and group search parameters, role synchronization, and service account credentials. Note that some parameters are commented out and can be enabled as needed.

```shell
#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

```

--------------------------------

### List Installed Components (kubectl)

Source: https://docs.qameta.io/allure-testops/install/kubernetes

Retrieves a list of all running components within the 'testops' namespace using kubectl. This command is essential for identifying active services and their status.

```bash
kubectl get all -n testops

```

--------------------------------

### Allure TestOps UAA Configuration - SMTP Example

Source: https://docs.qameta.io/allure-testops/install/v4-deb

This snippet shows an example configuration for sending emails using an SMTP server within the Allure UAA service. It includes parameters for host, port, credentials, and SSL settings. Ensure to replace placeholder values with your actual SMTP server details.

```shell
# please remember, this is an example, which won't work for you,
# you need to update your config with real SMTP server data.
ALLURE_MAIL_HOST=smtp.gmail.com
ALLURE_MAIL_PORT=465
ALLURE_MAIL_USERNAME=username
ALLURE_MAIL_PASSWORD=password
ALLURE_MAIL_FROM=noreply@example.com
ALLURE_MAIL_SMTP_AUTH=true
ALLURE_MAIL_SMTP_STARTTLS_ENABLE=true
ALLURE_MAIL_SMTP_STARTTLS_REQUIRED=true
ALLURE_MAIL_SMTP_SSL_ENABLE=true
ALLURE_MAIL_SMTP_SSL_TRUST=smtp.gmail.com

```

--------------------------------

### Add Qameta Repository to Yum

Source: https://docs.qameta.io/allure-testops/install/v4-rpm

This command adds the Qameta repository configuration to your system's yum configuration. It requires superuser privileges and replaces placeholder credentials with your provided username and password. Ensure you paste the entire command as a single unit.

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

```

--------------------------------

### Restart Allure TestOps Services

Source: https://docs.qameta.io/allure-testops/install/docker-compose

Restarts the Allure TestOps application by first stopping all services and then starting them again. This is useful for applying configuration changes or recovering from minor issues.

```bash
cd ~/testops
docker compose down; docker compose up -d
```

--------------------------------

### Download allurectl for Linux x64

Source: https://docs.qameta.io/allure-testops/ecosystem/allurectl

This snippet demonstrates how to download the allurectl binary for Linux on an x64 CPU using wget and make it executable with chmod. Ensure you have wget installed and appropriate permissions.

```bash
wget https://github.com/allure-framework/allurectl/releases/latest/download/allurectl_linux_amd64 -O ./allurectl
chmod +x ./allurectl
```

--------------------------------

### Testing LDAP Connection with ldapsearch (Environment Variable Example)

Source: https://docs.qameta.io/allure-testops/configuration/authentication/ldap

This shell command demonstrates testing your Allure TestOps LDAP configuration using `ldapsearch` with environment variables. It shows how to connect and search for a user, with arguments mapping to the corresponding LDAP environment variables.

```bash
ldapsearch \
    -H '${LDAP_URL}' \
    -D '${LDAP_LOGIN_SA}' \
    -w '${LDAP_LOGIN_SA_PASS}' \
    -b '${LDAP_USER_SEARCH_BASE}' \
    '${LDAP_USER_SEARCH_FILTER}'

```

--------------------------------

### Configure ALLURE_ENDPOINT for Docker Compose

Source: https://docs.qameta.io/allure-testops/migrations/to-3-184-2

This snippet illustrates setting the mandatory ALLURE_ENDPOINT environment variable for 'report' and 'uaa' services in a docker-compose setup. This URL is used for integration references.

```yaml
report:
  <snip>
  environment:
    # endpoint mandatory parameter
    ALLURE_ENDPOINT: https://<URL>:port
    <snip>

uaa:
  <snip>
  environment:
    # endpoint mandatory parameter
    ALLURE_ENDPOINT: https://<URL>:port
```

--------------------------------

### Update PostgreSQL Version in DEB/RPM Configuration

Source: https://docs.qameta.io/allure-testops/migrations/to-5113

Manually updates the PostgreSQL connection string in the Allure TestOps configuration file for DEB/RPM installations to ensure compatibility with version 15 or higher.

```bash
sudo sed -i 's/assumeMinServerVersion=11/assumeMinServerVersion=15/g' /opt/testops/conf/testops.conf

```

--------------------------------

### Run Tests with allurectl Watch (Concise Environment Variables)

Source: https://docs.qameta.io/allure-testops/ecosystem/allurectl

This example shows a more concise way to use 'allurectl watch' by defining all necessary parameters as environment variables, including the results path. This simplifies the command-line invocation, making it cleaner and less prone to errors.

```bash
export ALLURE_ENDPOINT=https://testops.example.com
export ALLURE_TOKEN=542dcd56-b0e2-4fdd-8ecf-bacf0f33d505
export ALLURE_PROJECT_ID=12
export ALLURE_LAUNCH_NAME="Hello, world"
export ALLURE_RESULTS=path/to/allure-results
export ALLURE_LAUNCH_TAGS="release, critical"

allurectl watch -- ./gradlew clean test

```

--------------------------------

### List All Installed Components with kubectl

Source: https://docs.qameta.io/allure-testops/install/v4-kubernetes

This command retrieves a list of all deployed components within the Kubernetes cluster. It's a fundamental step for understanding the current state of your Allure TestOps deployment.

```bash
kubectl get all

```

--------------------------------

### Get Allure TestOps System Logs

Source: https://docs.qameta.io/allure-testops/install/deb

Retrieves all log entries for the Allure TestOps service and saves them to a file named 'testops.log'. '--no-tail' ensures all logs are captured.

```bash
journalctl --no-tail -u testops > testops.log
```

--------------------------------

### Configure PostgreSQL Datasource for Migrations (Helm)

Source: https://docs.qameta.io/allure-testops/migrations/to-5113

Example configuration snippet for the `datasources` section in values.yaml, specifically for migration settings. It defines connection pool sizes for database migrations to minimize user impact.

```yaml
migrationDatasource:
# This section's purpose is to make the data migrations inside the database less visible for the end users.
# System will allocate separate pool of the database connections for the data migrations tasks and the migrations won't affect end users operations.
# maxDBMigrationConn defines the max connections number that will be used for the migrations tasks inside the database.
  maxDBMigrationConn: 2
# minDBMigrationIdle defines the min amount of connections to be kept in idle state. Leave it as it is unless recommended otherwise by the support
  minDBMigrationIdle: 0
# migrationSchedulerPoolSize defines the number of parallel threads that can be used for the migration tasks.
# The default value is 1, please do not increase this amount unless you have high workload and large database size.
  migrationSchedulerPoolSize: 1

```