QaaS.Runner.Storage 4.5.2

QaaS.Runner

Execution orchestration package for running QaaS test workflows from YAML configuration.

Contents

• Overview
• Packages
• Projects
• Quick Start
• ReportPortal
• Documentation

Overview

This repository contains one solution: QaaS.Runner.sln.

QaaS.Runner is published to NuGet and includes the runner runtime plus packaged project outputs from this solution that are required at runtime (sessions/assertions/storage orchestration flow).

Packages

Package	Latest Version	Total Downloads
QaaS.Runner

Projects

QaaS.Runner

• CLI/bootstrap entrypoint for run, act, assert, template, and execute verbs.
• Builds execution contexts and routes each execution type through the right logic chain.
• Orchestrates setup/teardown, optional Allure result serving, and optional ReportPortal launch finalization.

QaaS.Runner.Assertions

• Builds assertion runtime objects from configured hooks and filters.
• Executes assertions against session/data-source outputs.
• Writes Allure results, links, and attachments.
• Can also publish the same runner-produced assertion results into ReportPortal.

QaaS.Runner.Sessions

• Session runtime with staged action execution.
• Supports publishers, consumers, transactions, probes, and collectors.
• Produces session data and failure/flakiness metadata.

QaaS.Runner.Storage

• Storage abstraction for storing and retrieving serialized session data.
• Built-in implementations: filesystem and S3-compatible backends.
• Shared builder-based configuration for act/assert flows.

QaaS.Runner.Infrastructure

• Small shared cross-project helpers (filesystem and date/time utilities).

Quick Start

Install package:

dotnet add package QaaS.Runner

Upgrade package:

dotnet add package QaaS.Runner --version <target-version>
dotnet restore

ReportPortal

QaaS can publish the same assertion results it already writes to Allure into an existing ReportPortal instance.

Runtime rules:

• QaaS never creates ReportPortal projects, dashboards, filters, users, or API keys.
• Project routing is derived only from MetaData.Team, case-insensitively.
• Launches are grouped by Team + System.
• ExtraLabels and other metadata key/value pairs are emitted as ReportPortal attributes so teams can filter by labels such as Component, Area, or Owner.
• Each assertion is published as its own ReportPortal test item together with assertion message/trace, stack trace for broken assertions, session summaries, session failure history, assertion attachments, template YAML, and a generated assertion-context JSON artifact.
• Assertion links configured in QaaS remain active in Allure and are also written into ReportPortal logs.
• When ReportPortal is enabled but the endpoint, API key, or target project is invalid, QaaS logs a warning and skips ReportPortal publishing without crashing the runner or changing the exit code for otherwise passing runs.
• The default launch name is stable and derived from Team + System + Sessions, which keeps ReportPortal history grouped without creating new dashboards or projects.

Configuration sources:

Notes:

• Public QaaS.Configuration keeps ReportPortal disabled with null endpoint/key. Internal environments can publish a same-ID QaaS.Configuration package with internal ReportPortal defaults.
• YAML ReportPortal values always override QaaS.Configuration defaults for that run.
• Launch names are derived from the grouped team, system, and sessions unless you explicitly override the launch name/description in YAML.
• Allure remains active and unchanged when ReportPortal publishing is enabled.

Documentation

• Official docs: thesmoketeam.github.io/qaas-docs
• CI workflow: .github/workflows/ci.yml
• NuGet package page: QaaS.Runner on NuGet