Skip to content
CAI
Software that uses CAICheck a score

jpsuldo1/st2

47.3

Weak · 22 September 2026

58.1k

lines of production code

Python

primary language

5

measurements over time

CAI band scale
CAI trend line
CAI lens gauges

What this system is

This system is an enterprise-grade automation platform that orchestrates and executes distributed actions across Linux, Windows, and cloud environments. It provides a unified interface for managing workflows, sensors, and rules, supported by a comprehensive CLI and REST API. The architecture emphasizes modularity, security through RBAC, and extensibility via a pack-based content model.

How it got here

2014 — modularization and CLI development

93 changes.

This period focused on modularizing the codebase by splitting monolithic modules into smaller, focused components and establishing a robust build and packaging infrastructure for all packages. Significant work was also dedicated to the st2client, introducing a new command-line interface with structured output formatting and comprehensive model mapping.

2015 — RBAC, garbage collection, and exporter

56 changes.

This period focused on introducing role-based access control, automated data purging, and execution export capabilities. The team also added a debug information submission tool, expanded the Linux and ChatOps packs, and established a robust CI/CD pipeline for automated testing.

2016–2017 — runner expansion and infrastructure modernization

44 changes.

This period focused on significantly expanding the platform's execution capabilities by introducing new action runners for remote, Windows, and workflow orchestration, alongside a major refactoring of the streaming and CI infrastructure. The team also standardized testing and linting configurations while adding comprehensive test coverage for the new components.

Features

Add Linux system administration actions

Added a new set of Linux system administration actions to the linux pack, including check\_loadavg, check\_processes, cp, diag\_loadavg, dig, file\_touch, lsof, lsof\_pids, mv, netstat, netstat\_grep, pkill, rm, rsync, scp, service, traceroute, vmstat, and wait\_for\_ssh. These actions provide capabilities for monitoring system load and processes, managing files and directories, querying network and DNS information, and managing system services.

contrib/linux/actions · high confidence

Add Mistral v2 workflow runner

Users can now execute Mistral v2 workflows via a new 'mistral-v2' runner. This runner supports running individual workflows or selecting a specific workflow from a workbook, and allows skipping notifications for specific tasks.

_contrib/runners/mistral\v2 · high confidence

Add Mistral workflow validation

A new Mistral workflow validator has been introduced, allowing StackStorm to validate Mistral workflow definitions against the Mistral API. This includes support for both single workflows and workbooks, with specific error parsing for schema, YAQL, and action parameter issues. The validator is configured via Mistral connection properties such as insecure mode and CA certificate paths.

st2common/st2common/validators/workflow · high confidence

Add Python action examples for data parsing and iteration

Added new Python action examples to the contrib/examples/actions/pythonactions directory, including scripts for parsing JSON and YAML strings into objects, checking for prime numbers, generating Fibonacci sequences, and iterating through GitHub repository data. These examples demonstrate how to implement custom actions for data transformation and loop-based processing within the automation framework.

contrib/examples/actions/pythonactions · high confidence

Add Windows PowerShell script to display system uptime

A new PowerShell script, get\_uptime.ps1, has been added to the Windows actions examples. This script calculates and displays the system's uptime in days, hours, and minutes by querying the operating system's last boot time. Users can now use this script to quickly check how long their Windows machine has been running.

contrib/examples/actions/windows · high confidence

Add Windows Script Runner for remote PowerShell execution

A new Windows script runner has been added to enable remote execution of PowerShell scripts on Windows hosts. The change introduces a new \runner.yaml\ manifest and the corresponding \windows\_script\_runner.py\ implementation, which handles uploading scripts to a remote share, executing them via PowerShell, and managing timeouts and error states.

_contrib/runners/windows\_script\runner · high confidence

Add Windows command runner with remote execution support

Introduced a new Windows command runner that enables remote command execution on Windows hosts via winexe and smbclient. The change adds the runner implementation, a runner.yaml manifest defining parameters (host, username, password, command, timeout), and a comprehensive test suite covering command argument generation, script argument formatting, and share information parsing.

_contrib/runners/windows\_command\runner · high confidence

Add announcement and CloudSlang action runners

Introduced two new action runners: an announcement runner that dispatches events to a message bus, and a CloudSlang runner that executes CloudSlang flows via the command line. Both runners include configuration files and unit tests to support their respective execution models.

_contrib/runners/announcement\_runner, contrib/runners/cloudslang\runner · high confidence

Add bash example actions for exit codes, ping, and random number generation

New bash scripts are introduced to demonstrate basic shell scripting capabilities. Users can now use the bash\_exit\_code action to generate a random exit code, the bash\_ping action to perform network pings with a configurable count, and the bash\_random actions to generate and display random numbers. These additions provide practical examples for integrating shell-based actions into workflows.

_contrib/examples/actions/bash\_exit\_code, contrib/examples/actions/bash\_ping, contrib/examples/actions/bash\random · high confidence

Add example sensors for the new sensor interface

Added new example sensor implementations (sample\_sensor.py, sample\_polling\_sensor.py) and their corresponding YAML metadata files to demonstrate the updated sensor interface, including the use of sensor\_service for logging and dispatching triggers.

contrib/examples/sensors · high confidence

Add executable entry points for action runner, notifier, and result tracker

New executable scripts are added to the st2actions/bin directory, including runners.sh for managing worker processes across different init systems (systemd, upstart, sysv), and Python entry points for st2actionrunner, st2notifier, and st2resultstracker. These scripts enable the execution of StackStorm actions, notifications, and result tracking through standardized command-line interfaces.

st2actions/bin · high confidence

Add execution export worker and dumper integration

The st2exporter now includes a new worker (ExecutionsExporter) that consumes execution updates from the message queue and persists them to a configurable dump directory. The worker converts database models to API models, masks secrets, and queues completed executions for the dumper to process. A configuration file (config.py) registers options for the dump directory and logging, and the worker uses oslo\_config for consistent configuration handling.

st2exporter/st2exporter · medium confidence

Add experimental Mistral workflow validation endpoint

An experimental API endpoint for validating Mistral workflow definitions has been introduced. Users can now submit YAML definitions to this new validation controller, which leverages the existing Mistral validation utilities to check for errors and return structured results.

st2api/st2api/controllers/exp · medium confidence

Add file-based export dumper with date-organized subfolders

The exporter now includes a new \Dumper\ component that consumes execution data from a queue and writes it to JSON files. The dumper organizes exported files into subfolders named by date (YYYY-MM-DD) and persists a database marker to track the last processed timestamp, ensuring reliable incremental exports.

st2exporter/st2exporter/exporter · high confidence

Add green shell utilities for non-blocking command execution

A new \st2common.util.green.shell\ module was introduced, providing a \run\_command\ function that executes shell commands using eventlet-friendly subprocess handling. This allows commands to run without blocking, with support for custom pre-execution and kill functions, and returns a tuple indicating whether the process timed out.

st2common/st2common/util/green · high confidence

Add hello\_st2 example pack with sensor, action, and rule

A new example pack named hello\_st2 has been added to the contrib directory. It includes a Python sensor that dispatches a custom trigger, a shell-based action that greets users, a rule to react to the sensor's trigger, and associated policies for concurrency and retry behavior. This provides a complete, working example of how sensors, actions, and rules interact within StackStorm.

_contrib/hello\st2 · high confidence

Add new core actions: uuid, pause, noop, and announcement

The contrib/core/actions directory now includes several new core actions. A new 'uuid' action allows users to generate random UUIDs (supporting both uuid1 and uuid4 types). A 'pause' action enables workflows to pause execution for a specified duration, with an option to randomize the delay. Additionally, 'noop' and 'announcement' actions have been added to the core library, expanding the available built-in functionality for workflow control and messaging.

contrib/core/actions · high confidence

Add new operational and migration utility scripts

The tools directory now includes several new scripts to aid in system maintenance and debugging. These include a database cleanup utility (db\_cleanup.sh), a content diffing tool (diff-db-disk.py) to compare registered content against disk, and queue debugging utilities (queue\_consumer.py, queue\_producer.py) for testing message passing. Additionally, migration scripts have been added to update messaging queue structures (migrate\_messaging\_setup.py) and update rule and trigger metadata in the database (migrate\_rules\_to\_include\_pack.py, migrate\_triggers\_to\_include\_ref\_count.py).

tools · high confidence

Add nginx configuration for st2, st2api, st2auth, and stream endpoints

A new nginx configuration file (st2.conf) is introduced to expose the StackStorm web UI, API, authentication, and streaming endpoints. The configuration handles HTTP-to-HTTPS redirection, SSL termination, and reverse proxying to the respective backend services (st2api on port 9101, st2auth on port 9100, and stream on port 9102). It includes specific error handling for 502/503 states, disables proxy buffering and caching for streaming, and enables performance optimizations like sendfile and TCP optimizations.

conf/nginx · high confidence

Add noop runner for testing and debugging

A new 'noop' runner has been added to the system, providing a simple action that returns a static success response regardless of input parameters. This includes the core Python implementation, the runner configuration file, and associated unit and integration tests to verify its behavior.

_contrib/runners/noop\runner · high confidence

Add send\_mail action with local file attachment support

A new send\_mail shell script action has been added to the core actions. It supports sending emails with local file attachments, configurable content types, and a dynamic footer. The script validates the presence of the sendmail binary and handles both empty and non-empty body scenarios.

_contrib/core/actions/send\mail · high confidence

Add shell autocomplete for st2 CLI

A new shell completion script (st2.complete.sh) is added to enable tab-completion for the st2 command-line interface, allowing users to press Tab to auto-complete commands and arguments in supported shells.

st2client/conf · high confidence

Add st2auth executable entry point

A new executable script, st2auth/bin/st2auth, has been added to the repository. This Python 2.7 script serves as the entry point for the st2auth service, invoking the main function from st2auth.cmd.api. This change enables the st2auth component to be run directly as a standalone command.

st2auth/bin · high confidence

Add st2exporter command-line entry point

The st2exporter application now includes a dedicated command-line entry point (st2exporter\_starter.py) that initializes the exporter service, starts the background worker, and handles graceful shutdown. This change enables users to run the exporter directly from the command line, with proper logging and signal handling.

st2exporter/st2exporter/cmd · high confidence

Add st2exporter configuration and entry point

Introduced the st2exporter component with a Python 2.7 entry point script (st2exporter/bin/st2exporter) and associated configuration files. These include logging setups for console, file, and audit handlers, a development configuration specifying AMQP messaging at 127.0.0.1:5672, and a syslog handler configuration. This enables the exporter to log to console, files, and syslog, and connect to the message queue.

st2exporter/conf · medium confidence

Add test packs for CPU load average checks and error code validation

New test packs have been added to the repository to support integration and unit testing scenarios. The 'checks' pack introduces a Python action that reads /proc/loadavg and /proc/cpuinfo to calculate and display CPU load averages, while the 'errorcheck' pack provides a shell script action designed to return specific non-zero exit codes for testing error handling. These additions provide reusable components for validating script behavior and exit codes within the test environment.

st2tests/testpacks · high confidence

Added StackStorm lint configuration files

The repository now includes a \lint-configs\ directory containing shared linting configurations for Python (\.flake8\, \.pylintrc\) and a \README.md\ explaining how to use them as a git subtree. This provides a centralized set of linting rules for developers to adopt across StackStorm projects.

lint-configs · high confidence

Added build and packaging infrastructure for st2reactor

The st2reactor component now includes a complete build and packaging setup. A new \setup.py\ script enables standard Python package installation and wheel building, while a \Makefile\ provides targets for generating RPM and DEB packages. The build process is configured to dynamically parse the version from \\_\init\\_.py\, and a \dist\_utils.py\ helper handles dependency resolution and a Vagrant-specific workaround. Additionally, \MANIFEST.in\ and \setup.cfg\ are added to control file inclusion and test configuration.

st2reactor, st2stream · high confidence

Added configuration files for st2auth deployment and logging

Added new configuration files to support the st2auth service. This includes an Apache sample configuration enabling SSL and external authentication, logging configurations for console, file, and syslog outputs, and a development htpasswd file for testing.

st2auth/conf · medium confidence

Added sample configuration files for StackStorm high-availability deployment

New sample configuration files have been added to the conf/HA directory to support high-availability setups. This includes an nginx configuration template for the controller node (st2.conf.controller.sample) that sets up SSL termination and reverse proxying to backend services, a corresponding template for the worker node (st2.conf.blueprint.sample) with direct proxying to local services, and a st2.conf.sample for the application itself, configuring endpoints, logging, and messaging to work in a multi-node environment.

conf/HA · high confidence

Added st2stream executable entry point

A new executable script has been added at st2stream/bin/st2stream, allowing users to invoke the st2stream command-line interface directly from the system path or via the bin directory. This change enables the tool to be run as a standalone command, bridging the Python 2.7 environment with the st2stream.cmd.api.main() entry point.

st2stream/bin · high confidence

Added ubuntu\_pkg\_info example action

Added the ubuntu\_pkg\_info example action, which runs 'apt-cache policy' and outputs the result as JSON. The implementation includes the main script (ubuntu\_pkg\info.py) and supporting library files (lib/\\init\\_.py and lib/datatransformer.py) to handle command execution and data transformation.

_contrib/examples/actions/ubuntu\_pkg\info · high confidence

Automated CI/CD pipeline and Mistral integration tests

The CI/CD pipeline is now fully automated via new scripts in the scripts/travis directory. The build process is orchestrated by build.sh, which routes tasks to specific make targets for checks, unit, integration, and Mistral tests. The environment is prepared by create-and-mount-ramdisk.sh and install-and-run-mistral.sh, which handle MongoDB setup and configuration. The integration test environment is configured by prepare-integration.sh, which sets up the system user and development environment. Additionally, setup-mistral.sh automates the installation and configuration of the Mistral workflow engine, including PostgreSQL setup, database initialization, and service configuration, enabling automated testing of Mistral-related functionality.

scripts/travis · high confidence

Expanded Mistral workflow examples and ActionChain templates

The examples pack received a large set of new Mistral workflow definitions and ActionChain templates. Mistral examples now cover branching, error handling, retry, cancellation, and subworkflow rerun scenarios, alongside Jinja-based key-value pair access. ActionChain examples demonstrate data filtering (JSON, regex, version, time, YAML, and encryption) and variable publishing. The collection also includes utility actions for local/remote shell commands, Python scripts, and HTTP requests.

contrib/examples/actions · high confidence

Expanded Mistral workflow examples and templates

Added a comprehensive set of new Mistral workflow examples to the \contrib/examples/actions/workflows\ directory. These include templates for basic execution, branching, error handling, retry logic, cancellation, and subworkflow management. The collection also introduces Jinja2-based workflow definitions alongside the existing YAQL-based ones, providing users with modern syntax options for common patterns such as parallel execution, joins, and environment variable access.

contrib/examples/actions/workflows · high confidence

Initial packaging and build infrastructure for st2auth

The st2auth component now includes a complete build and packaging setup, including a Makefile for managing RPM, DEB, and wheel builds, along with a MANIFEST.in to define source distribution contents. The project uses a shared dist\_utils.py to handle requirements parsing and a Vagrant-specific workaround, while in-requirements.txt and setup.py define the package dependencies and metadata. This establishes the foundation for building and distributing the st2auth package.

st2auth · high confidence

Initial packaging and distribution setup for st2client

The st2client component is now fully packaged for distribution, including an Apache 2.0 license file, a MANIFEST for source distributions, and a setup.py configuration that defines the package metadata, dependencies (such as requests, six, and pyyaml), and the 'st2' CLI entry point. This change establishes the build infrastructure (Makefile targets for RPM, DEB, and wheels) and ensures the package can be built and installed as a standalone Python package.

st2client · high confidence

Initial release of the StackStorm CLI client

The st2client package is introduced, providing a command-line interface for interacting with the StackStorm API. This release establishes the foundational structure for the CLI, including a base application class for handling authentication and configuration, a client class for managing API endpoints and resource managers, and a shell entry point that registers commands for actions, executions, policies, and more. Users can now authenticate, manage resources, and configure the CLI via environment variables, command-line arguments, or a config file.

st2client/st2client · high confidence

Initial release of the st2exporter component

The st2exporter component is introduced, providing a new capability to listen to execution updates from RabbitMQ and create JSON files from them. This change adds the necessary build infrastructure (setup.py, Makefile, requirements) and source files to package and install the exporter, including a Vagrant compatibility fix in dist\_utils.py.

st2exporter · high confidence

Introduce HTTP runner with basic authentication and proxy support

Adds a new HTTP runner that allows executing HTTP actions with support for basic authentication (username/password), HTTP/HTTPS proxies, and SSL certificate verification. The runner accepts headers, cookies, and query parameters, and handles JSON response parsing.

_contrib/runners/http\runner · high confidence

Introduce HTTPS support and secure mode for ST2 Auth API

The ST2 Auth API service now supports HTTPS via a new 'use\_ssl' configuration option. When 'use\_ssl' is enabled, the service validates that the specified certificate and private key files exist, raising an error if they are missing. This allows the auth service to serve secure connections, with the option to disable SSL for proxy scenarios.

st2auth/st2auth/cmd · medium confidence

Introduce RBAC system for role definitions, permissions, and sync

The RBAC module in st2common has been significantly expanded to support a new role-based access control system. This includes a loader for reading role definitions and user role assignments from disk files, a syncer to synchronize these definitions with the database, and a comprehensive set of permission resolvers for various resource types such as actions, sensors, rules, webhooks, and executions. The system also introduces new permission types and constants to define granular access rights across the platform.

st2common/st2common/rbac · high confidence

Introduce ST2 Stream API entry point

Added the \st2stream/st2stream/cmd/api.py\ module which serves as the entry point for the ST2 Stream API. This new command-line interface initializes the application using \eventlet\ for asynchronous WSGI serving, configures the stream-specific configuration, and handles graceful shutdown of long-running stream requests.

st2stream/st2stream/cmd · high confidence

Introduce action-chain runner with configurable display\_published parameter

A new action-chain runner is introduced, enabling the execution of linear action chains. The runner includes a \display\_published\ parameter, which defaults to \True\ to ensure intermediate published variables are stored and displayed by default.

_contrib/runners/action\_chain\runner · high confidence

Introduce base model classes for serialization

A new models package has been added to st2common, providing a base class (DictSerializableClassMixin) that enables objects to be serialized into dictionaries, with support for masking secrets during serialization. This establishes a foundational abstraction for data models within the application.

st2common/st2common/models · high confidence

Introduce base policy applicator and concurrency policy implementation

Added a new policy application framework in st2common/policies, including a base ResourcePolicyApplicator class with before/after hooks and a concrete BaseConcurrencyApplicator that enforces action concurrency limits. This provides the underlying mechanism for policy enforcement, with the concurrency applicator supporting delay or cancel actions based on configured thresholds.

st2common/st2common/policies · high confidence

Introduce configurable garbage collection service for purging old data

A new garbage collector service has been added to the reactor, enabling automatic purging of old action executions and trigger instances from the database. The service is configurable via the 'garbagecollector' section, allowing users to set the collection interval and the minimum TTL (in days) for both action executions and trigger instances. A minimum TTL of 7 days is enforced to prevent accidental deletion of recent data. Users can also trigger a manual collection run by sending the SIGUSR2 signal to the service.

_st2reactor/st2reactor/garbage\collector · medium confidence

Introduce debug info submission tool with sensitive data redaction

A new debug tool is added to collect and submit diagnostic information. The tool includes a script (st2-submit-debug-info) and supporting modules that process configuration files from StackStorm and Mistral to redact sensitive credentials (such as database passwords and messaging URLs) before submission. It also removes sensitive configuration files (config.yaml) from content packs. The submission endpoint is configured to upload encrypted tarballs to the S3 bucket st2debuginfo.s3.amazonaws.com.

st2debug/st2debug · high confidence

Introduce debug information submission tool

Added the st2debug/st2debug/cmd/submit\_debug\_info.py script, which collects and submits debugging information to StackStorm. The tool gathers logs, configuration files, content packs, and system details, then packages them into a tarball. It supports encryption via GPG, uploads the archive to an S3 bucket, and allows users to provide additional context (name, email, comment) during submission. The implementation uses yaml.safe\_dump for configuration handling, reads GPG keys from a YAML config file, and ensures robustness against permission issues and missing binaries.

st2debug/st2debug/cmd · high confidence

Introduce new API and DB models for core StackStorm entities

A new API model layer has been introduced in st2common, defining the data structures for key system entities including Action, LiveAction, ActionExecution, Pack, User, ApiKey, and Policy. These models define the JSON schema and validation rules for the REST API, mapping to corresponding database models. This change establishes the contract for how clients interact with these resources, including fields like 'enabled' for actions and runners, 'pack' references, and execution status tracking.

st2common/st2common/models/api · high confidence

Introduce new CLI commands for RBAC, API spec, and config validation

Added new command-line tools to the st2common package: a script to apply RBAC definitions and role assignments, a utility to purge execution and trigger instance data, a script to generate the OpenAPI specification, a validator to check the API spec against model classes, and a tool to validate configuration files against a schema. These additions provide users with new ways to manage security policies, clean up old data, verify API documentation, and ensure configuration correctness.

st2common/st2common/cmd · high confidence

Introduce new CLI entry points for reactor components

New executable scripts have been added to the st2reactor/bin directory to provide command-line interfaces for the rules engine, sensor container, garbage collector, and trigger refiring functionality. These scripts serve as entry points that invoke the corresponding internal commands (rulesengine, sensormanager, garbagecollector, and trigger\_re\_fire), enabling users to directly manage and test these reactor components from the command line.

st2reactor/bin · high confidence

Introduce new REST API controller base classes and utilities

Added new base controller classes and utility modules in the st2api package to standardize REST API behavior. The new \BaseRestControllerMixin\ provides common query parameter parsing and secret masking logic, while \ResourceController\ offers a shared implementation for listing, filtering, sorting, and limiting results. Additionally, a \RootController\ is introduced to display the API version and documentation URL on the root path.

st2api/st2api/controllers · high confidence

Introduce new st2ctl and utility scripts for service management and validation

A new st2ctl script is introduced to manage StackStorm services, supporting systemd, upstart, and sysvinit service managers. The script includes commands for starting, stopping, and restarting components, as well as reloading content with options to register triggers, sensors, rules, runners, actions, aliases, policies, configs, and setup virtualenvs. Additionally, several new utility scripts are added: st2-check-license for validating license keys, st2-generate-api-spec for generating API specifications, st2-generate-symmetric-crypto-key for generating cryptographic keys, st2-purge-executions and st2-purge-trigger-instances for purging data, st2-register-content for registering content, st2-run-pack-tests for running pack tests, st2-self-check for self-checking the installation, st2-validate-api-spec for validating API specs, and st2-validate-pack-config for validating pack configurations. These scripts enhance the management and validation capabilities of the StackStorm platform.

st2common/bin · high confidence

Introduce new v1 authentication and token validation endpoints

The st2auth service now exposes a new v1 API for authentication and token management. Users can obtain tokens via the new token controller and verify token validity through a dedicated validation endpoint. The implementation supports both 'proxy' and 'standalone' authentication modes, returning HTTP 201 on successful token generation and providing a validation response indicating whether a token is valid, expired, or not found.

st2auth/st2auth/controllers/v1 · high confidence

Introduce process-based sensor container with partitioning support

The sensor container has been refactored to run each sensor in a separate, isolated process, improving stability and fault isolation. A new \ProcessSensorContainer\ manages the lifecycle of these processes, including automatic respawning of failed sensors. To support distributed deployments, the update introduces a pluggable partitioning system (default, KV store, file-based, and hash-based) that allows multiple sensor containers to share the workload by each managing a specific subset of sensors. Additionally, a \SensorWrapper\ is now used to load and execute sensors in a sandboxed environment, passing necessary configuration and environment variables.

st2reactor/st2reactor/container · high confidence

Introduce remote command runner for executing fixed-system-user commands

A new remote command runner named 'remote-shell-cmd' is now available in the contrib directory, allowing users to execute arbitrary Linux commands on remote hosts via SSH. The runner supports configuration of working directories (defaulting to /tmp), environment variables, parallel execution, and sudo privileges. It is registered with the alias 'run-remote' and includes parameters for host selection, timeouts, and authentication details.

_contrib/runners/remote\_command\runner · high confidence

Introduce st2client models for CLI resource representation

The st2client package now includes a comprehensive set of Python models that map to StackStorm API resources, enabling the CLI to interact with the server. This change adds model classes for core resources including Action, RunnerType, LiveAction (Execution), ActionAlias, Config, KeyValue, Pack, Policy, RBAC (Roles and Assignments), Reactor components (Sensor, Trigger, TriggerInstance, Rule, RuleEnforcement), Timer, Trace, and Webhook. These models define the structure for serializing and deserializing API responses, allowing the CLI to parse and display resource data effectively.

st2client/st2client/models · high confidence

Introduce structured CLI formatters for JSON, YAML, and table output

The st2client now supports structured output formatting via new formatters for JSON, YAML, and tabular data. Users can now request JSON or YAML output for commands like st2 run and st2 execution, with keys sorted and sensitive parameters masked. The table formatter dynamically adjusts column widths to fit the terminal, handles empty results without crashing, and supports dotted lookups and custom attribute ordering. This provides more flexible and robust CLI output options.

st2client/st2client/formatters · high confidence

Introduce structured exception classes for StackStorm components

The st2common package now includes a comprehensive set of new exception classes organized by domain, including authentication (e.g., TokenNotProvidedError, ApiKeyNotFoundError), RBAC (e.g., AccessDeniedError, ResourceAccessDeniedError), action runners, sensors, and database operations. These structured exceptions replace generic error handling with specific, catchable types, allowing for more precise error handling and more informative error messages for users and developers.

st2common/st2common/exceptions · high confidence

Introduce the new RulesEngine for processing trigger instances

The st2reactor/rules directory now contains a complete, new implementation of the rules engine, including the RulesEngine, RuleEnforcer, RuleFilter, and RulesMatcher classes. This refactors the previous monolithic reactor logic into a modular system that handles trigger instances, matches rules against them, and enforces actions. The change also introduces a dedicated configuration section for the rules engine, separating it from the sensor container configuration.

st2reactor/st2reactor/rules · high confidence

Introduction of Python Runner for executing Python-based actions

A new Python runner has been added to the system, enabling the execution of Python scripts as actions. This includes the core runner implementation in \python\_runner.py\ and its configuration in \runner.yaml\. The runner supports configurable environment variables and a default action timeout of 600 seconds. It handles the execution of Python actions via a wrapper script, managing dependencies and environment setup for each action.

_contrib/runners/python\runner · high confidence

New API validators for actions, triggers, and criteria

The st2common/st2common/validators/api package now includes dedicated validation modules for actions (action.py), reactor triggers (reactor.py), and misc utilities (misc.py). This introduces structured validation for action parameters (including immutability, default values, and position uniqueness), trigger parameter and payload schema enforcement with a new system.validate\_trigger\_parameters configuration option, and criteria object validation for reactor rules. Additionally, a check prevents updates or deletions of resources belonging to system-level packs.

st2common/st2common/validators/api · high confidence

New CLI utility modules for formatting, HTTP, and interactive input

The st2client now includes a suite of utility modules to enhance the command-line interface experience. Users will see colored status indicators for task execution, human-readable timestamp formatting, and interactive configuration prompts. The HTTP client now supports SSL verification, API key authentication, and debug logging of cURL request lines. Additionally, the CLI now handles carriage returns and terminal size detection more robustly, and provides a task indicator for progress updates.

st2client/st2client/utils · high confidence

New ChatOps actions for execution formatting, alias matching, and result posting

The chatops pack introduces several new actions to improve how users interact with and view execution results in chat channels. The \format\_execution\_result\ action formats execution data using Jinja2 templates, supporting custom result formatting via action aliases. The \match\ action allows users to find matching action aliases for a given text. The \match\_and\_execute\ action combines matching and execution, waiting for the execution to complete before returning the result. Additionally, \post\_message\ and \post\_result\ actions enable posting arbitrary messages and execution results to specified channels, with support for user notifications, whispering, and extra adapter-specific parameters. These changes enhance the ChatOps experience by providing more control over message formatting, alias matching, and result reporting in chat platforms.

contrib/chatops/actions · high confidence

New Jinja2 filters for data, regex, time, and versioning

Added new Jinja2 filters to the st2common library, enabling users to perform common data transformations directly in templates. This includes \to\_json\_string\ and \to\_yaml\_string\ for serialization, \json\_escape\ for escaping characters, and a suite of regex filters (\regex\_match\, \regex\_replace\, \regex\_search\, \regex\_substring\) for pattern matching and replacement. Additionally, the update introduces \to\_human\_time\_from\_seconds\ for human-readable time formatting, \decrypt\_kv\ for secure key-value decryption, and \version\_compare\ (along with \version\_more\_than\, \version\_less\_than\, \version\_equal\, \version\_match\, \version\_bump\_major\, \version\_bump\_minor\, and \version\_strip\_patch\) for semantic versioning operations.

st2common/st2common/jinja · high confidence

New command-line utilities for testing rules, refiring triggers, and managing the garbage collector

The st2reactor component now includes new command-line entry points: a rule tester for validating rule logic against trigger instances, a trigger re-firing utility to manually re-dispatch trigger instances, and a garbage collector service. These additions provide new ways to interact with the reactor system, including testing rules and managing internal state cleanup.

st2reactor/st2reactor/cmd · high confidence

New concurrency and retry policy applicators for actions and workflows

The st2actions/policies module now includes new policy applicators: ConcurrencyApplicator and ConcurrencyByAttributeApplicator, which enforce action concurrency limits by delaying or canceling executions when thresholds are reached, and ExecutionRetryPolicyApplicator, which automatically retries failed or timed-out actions with configurable delays and maximum retry counts.

st2actions/st2actions/policies · high confidence

New configuration files for log rotation and environment-specific settings

Added logrotate configuration for all StackStorm services (rules engine, auth, API, stream, notifier, etc.) to manage log file rotation and signal handlers. Introduced new configuration files for development (st2.dev.conf), production (st2.prod.conf), package (st2.package.conf), and tests (st2.tests.conf, st2.tests1.conf) to support separate environments with distinct settings such as database hosts, logging paths, and security options. Also added a sample configuration file (st2.conf.sample) and a demo crypto key file for key-value store encryption.

conf · high confidence

New content registration and loading infrastructure

A new content registration system has been introduced, allowing users to explicitly register resources such as triggers, sensors, actions, rules, aliases, policies, and configs via the st2-register-content script. The system now supports registering content from specific packs, setting up Python virtual environments for pack actions, and validating pack names and requirements. Additionally, a new content loader infrastructure has been added to load actions, sensors, and other content from packs, with support for multiple base directories and duplicate pack handling.

st2common/st2common/content · high confidence

New default ChatOps template for execution notifications

A new default Jinja2 template for ChatOps notifications has been introduced, defining how execution status, ID, web URL, elapsed time, and structured results are rendered for various runner types (e.g., http-request, python-script, shell commands). This template standardizes the output format for ChatOps integrations, ensuring consistent and readable messages for different execution contexts.

contrib/chatops/actions/templates · high confidence

New local shell runner for executing commands and scripts

A new local runner is introduced that allows executing arbitrary Linux commands and shell scripts locally. The runner supports running commands as a fixed user, with optional sudo privileges, environment variable injection, and configurable timeouts. It maps process exit codes to live action statuses, including a new mapping for SIGTERM (SIGKILL) to an 'abandoned' status. The implementation includes the runner module, its configuration manifest, and integration tests verifying command execution, script execution, timeout handling, and environment variable propagation.

_contrib/runners/local\runner · high confidence

New mock classes for testing actions, sensors, and executions

Added mock implementations for testing components, including MockActionService, MockDatastoreService, MockActionRunner, MockSensorService, MockLiveActionPublisher, and MockExecutionPublisher. These classes provide simplified, in-memory or mock-based alternatives to the real services, enabling unit tests to run without external dependencies or complex setups.

st2tests/st2tests/mocks · high confidence

New pack management actions for installation, configuration, and environment setup

The pack management subsystem now exposes a comprehensive set of actions for managing StackStorm packs. Users can now install, uninstall, load, and unload packs, as well as search and view pack details. New actions allow for managing Python virtual environments (setup, update, and pre-run steps) and retrieving configuration variables. The install and load actions support registering specific content types (actions, sensors, rules, etc.) and include parameters for environment variables, force installation, and timeout adjustments.

contrib/packs/actions · high confidence

New remote script runner with SSH passphrase support

A new remote script runner (remote-shell-script) has been added to the contrib/runners directory, enabling execution of scripts on remote hosts via SSH. This runner supports passing a passphrase for password-protected private SSH keys, and allows configuration of the remote working directory (dir) and local working directory (cwd).

_contrib/runners/remote\_script\runner · high confidence

New scripts for requirements management and version population

Added new build and packaging scripts: \fixate-requirements.py\ generates pinned \requirements.txt\ files by merging component-specific \in-requirements.txt\ files with a central \fixed-requirements.txt\ (requiring pip 6.1+); \dist\_utils.py\ provides utilities to parse requirements and apply a Vagrant-specific workaround; \populate-package-meta.sh\ and \populate-version.sh\ automate the generation of package metadata and version strings. These scripts streamline the dependency pinning and packaging process for the StackStorm components.

scripts · high confidence

New system and file utility modules for debug tooling

Added new utility modules for the debug tool: \fs.py\ provides functions to list files, retrieve directory paths, copy, and remove files and directories; \git\_utils.py\ adds a function to retrieve the latest git revision hash; \system\_info.py\ introduces functions to retrieve CPU and memory information, and to list installed packages on Debian or Red Hat-based systems. These utilities support the debug workflow by providing reliable access to system state and file operations.

st2debug/st2debug/utils · high confidence

New system models for action execution and chaining

The system models for action execution and chaining have been introduced, including \ShellCommandAction\, \ShellScriptAction\, \RemoteAction\, and \RemoteScriptAction\ to handle local and remote command/script execution. Additionally, \ActionChain\ and \Node\ models are added to support sequential action chains with support for \on-success\/\on-failure\ branching, \publish\ variables, and \notify\ settings. A \ResourceReference\ class is also added to manage references to content pack resources, and \UserKeyReference\ is introduced for user-scoped key-value lookups.

st2common/st2common/models/system · high confidence

Packaging and build infrastructure for st2actions

The st2actions component now includes a complete Python packaging setup, including a setup.py that defines the package metadata, dependencies, and scripts (st2actionrunner, st2notifier, st2resultstracker). A new dist\_utils.py module handles requirement parsing and a Vagrant-specific workaround. The build process is supported by a Makefile with targets for wheelhouse, RPM, and DEB packages, along with MANIFEST.in, setup.cfg, and in-requirements.txt to manage dependencies and file inclusion.

st2actions · high confidence

Packaging infrastructure added for st2debug

The st2debug component now includes a complete Python packaging setup, including a new setup.py, a Makefile for building RPM and DEB packages, and a MANIFEST.in to ensure all necessary files are included in the distribution. A shared dist\_utils.py module is introduced to handle requirements parsing and a Vagrant-specific workaround, while an in-requirements.txt file lists the component's dependencies.

st2debug · high confidence

Python runner now exposes the Action class for direct command-line execution

The Python runner now imports and exposes the \Action\ class from \st2common.runners.base\_action\ in its public API. This change allows Python runner actions to be executed directly from the command line, making it easier to test and reuse action files as standalone scripts.

st2actions/st2actions/runners · medium confidence

Standardized project configuration and build infrastructure

The project now includes standardized configuration files for linting (flake8, pylint), coverage reporting (codecov, coveragerc), and CI/CD (CircleCI, Scrutinizer). A new Makefile centralizes build, test, and linting targets, while a structured CHANGELOG.rst documents all changes. These changes improve code quality enforcement, test coverage tracking, and release management.

(repo-wide) · high confidence

st2tests package now supports standard Python distribution and RPM/DEB builds

The st2tests component now includes a full Python packaging setup (setup.py, MANIFEST.in, setup.cfg) and build infrastructure (Makefile, dist\_utils.py) that enables users to publish st2tests as a distributable package and include it in st2 packages. This change introduces support for building RPM and DEB packages, as well as wheel distributions, allowing st2tests to be installed via standard Python package management tools.

st2tests · medium confidence

Architecture

Mistral workflow utilities moved to st2common

Mistral-related workflow utilities, including the main implementation file, have been moved to the st2common package. This change consolidates shared workflow logic, making it available for reuse across different components of the system.

st2common/st2common/util/workflow · high confidence

Notifier module restructured with dedicated configuration and scheduling components

The notifier functionality has been reorganized into a dedicated package under st2actions, introducing separate modules for core notification logic, configuration, and the action rescheduler. This change isolates the rescheduler code within the notifier package where it is used, and provides a standalone configuration file for the notifier and resultstracker, allowing for independent tuning of scheduler intervals and delayed execution recovery settings.

st2actions/st2actions/notifier · high confidence

Refactor action execution into dedicated scheduler and worker components

The st2actions package has been restructured to separate concerns: a new scheduler component handles the initial dispatch and policy application for live actions, while a worker component manages the actual execution and cancellation of actions. This change introduces a new config.py for registering action runner options, a scheduler.py for managing the queue of requested actions, and a worker.py for handling the execution queue and cancellation requests, improving code organization and maintainability.

st2actions/st2actions · high confidence

Refactor pack management actions into a dedicated module

The pack management actions (download, delete, get\_installed, register, search, setup\_virtualenv, show\_remote, unload, and virtualenv\_setup\_prerun) have been reorganized into the new \contrib/packs/actions/pack\_mgmt\ directory. This change consolidates pack lifecycle operations—including installation, uninstallation, registration, and virtual environment setup—into a single, cohesive module, improving code reuse and maintainability for pack management features.

_contrib/packs/actions/pack\mgmt · high confidence

Refactored and expanded utility modules in st2common.util

The st2common.util package has been reorganized and expanded with new utility modules for handling authentication (auth.py), API URL construction (api.py), argument parsing (argument\_parser.py), casting and type conversion (casts.py), configuration loading and parsing (config\_loader.py, config\_parser.py), crypto operations (crypto.py), date/time handling (date.py), debugging (debugging.py), enums (enum.py), file system operations (file\_system.py), and green thread dispatching (greenpooldispatch.py). These changes consolidate common functionality into reusable utility functions, improving code organization and maintainability across the st2common module.

st2common/st2common/util · high confidence

Reorganize persistence layer into individual module files

The persistence layer in st2common has been reorganized from a single monolithic file into separate modules for each resource type (e.g., action, auth, execution, keyvalue, liveaction, pack, policy, rbac, reactor, rule, sensor, trace, and trigger). This change improves code maintainability and reduces import dependencies by splitting the large persistence module into smaller, focused files.

st2common/st2common/persistence · high confidence

Behavioural changes

Add Pylint plugins to recognize dynamic attributes in API and DB models

New Pylint plugins have been added to help the linter understand dynamically assigned attributes. For API models that define attributes via a 'schema' attribute using JSON schema, the plugin now correctly infers property types for dicts, lists, and other types, and handles null types. For DB models (classes ending in 'DB'), the plugin now recognizes the 'id' field implicitly declared by mongoengine. These changes reduce false-positive linting errors for these specific model patterns.

_pylint\plugins · high confidence

Added migration scripts for datastore scope and runner registration

Three new migration scripts are introduced to handle version-specific upgrades. The v1.5 script adds a 'secret' and 'scope' fields to existing datastore items, while the v2.1 script updates scope values from 'SYSTEM'/'USER' to 'FULL\_SYSTEM'/'FULL\_USER'. Additionally, a shell script is added to register runners using st2ctl. These scripts ensure data integrity and proper configuration during upgrades.

st2common/bin/migrations · high confidence

Centralize and expand system constants in st2common

The st2common package now includes a new constants subpackage that consolidates previously scattered string literals, regex patterns, and configuration values into dedicated modules (e.g., action, auth, keyvalue, pack, rules, runners, secrets, sensors, system, timer, trace, triggers, and types). This includes new live action statuses (requested, delayed, abandoned), authentication mode and header constants, datastore scope and separator definitions, pack name and regex patterns, runner timeout and environment variable prefixes, and resource type enumerations, providing a single source of truth for these values across the application.

st2common/st2common/constants · high confidence

Centralized policy metadata definitions

The metadata definitions for concurrency and retry policies have been moved from st2actions to st2common, centralizing policy configuration. The concurrency policies now support an 'action' parameter that lets users specify whether to delay or cancel executions when the concurrency threshold is reached.

st2common/st2common/policies/meta · medium confidence

Centralized query execution and state cleanup in st2common

The base Querier class and its associated logic for querying external services and updating action results have been moved to st2common/st2common/query. This refactor centralizes the query execution loop, result polling, and state management. Additionally, the system now automatically deletes the execution state object when a query fails or when an action completes, ensuring cleaner state handling.

st2common/st2common/query · high confidence

Centralized service layer for core platform capabilities

The \st2common/st2common/services\ directory has been reorganized into a dedicated service layer, introducing new modules for access control (token management), action execution, configuration, coordination, datastore, key-value lookups, pack management, RBAC, rules, sensor watching, and execution tracking. This refactoring consolidates previously scattered logic into a structured set of service functions, enabling better code reuse and clearer separation of concerns for features like token generation, action execution requests, and permission grants.

st2common/st2common/services · high confidence

Database model refactoring and RBAC support

The database models have been reorganized into individual files (e.g., action.py, auth.py, execution.py) and updated to support Role-Based Access Control (RBAC). This includes adding 'uid' and 'ref' fields to models like Action, Rule, and Policy, and introducing new models for RBAC such as PermissionGrantDB and GroupToRoleMapping. Additionally, the codebase now supports SSL connections to MongoDB and implements secret masking for sensitive fields like API keys and execution parameters.

st2common/st2common/models/db · high confidence

File watch sensor now accepts file paths via trigger parameters

The Linux pack's file watch sensor has been updated to receive the file path to monitor through trigger parameters rather than a config file. Users can now define a rule that specifies the file path to tail, allowing for more dynamic and flexible monitoring of files. The sensor still emits the same payload structure, but the method of providing the file path has changed to use a rule-based approach.

contrib/linux/sensors · medium confidence

Introduce RBAC and system user configuration options

The st2common module now registers configuration options for Role-Based Access Control (RBAC), including an 'enable' flag and 'sync\_remote\_groups' setting. Additionally, the 'system\_user' configuration group has been introduced, allowing administrators to define the default system user (defaulting to 'stanley') and its associated SSH key file. These changes enable finer-grained access control and system user management within the common configuration layer.

st2common/st2common · high confidence

Introduce dedicated schema validation for action parameters

The schema validation logic for action parameters has been separated into its own dedicated schema (\action\_params.json\) and validation function (\get\_schema\_for\_action\_parameters\). This change ensures that the \type\ attribute for action parameters cannot be specified as an array, preventing validation errors. The custom validator now supports assigning default values to nested object and array properties, and allows \required: true\ to be used in combination with a default value without failing validation.

st2common/st2common/util/schema · medium confidence

Introduce new sensor base classes and configuration structure

The sensor module now includes new base classes for passive and active (polling) sensors, providing a cleaner abstraction for sensor implementations. Additionally, the configuration for the sensor container is explicitly defined in a new config file, registering options for logging, partitioning, and sensor filtering.

st2reactor/st2reactor/sensor · high confidence

Introduce st2stream as a standalone WSGI application with OpenAPI routing

The st2stream component has been refactored into a standalone WSGI application that uses an OpenAPI router for request handling. This change introduces dedicated configuration files for logging (console, file, and syslog) and separates stream-specific settings (host, port, heartbeat) from the global API configuration. The application now explicitly manages RabbitMQ connections for event listening and includes middleware for error handling, CORS, logging, and request IDs, ensuring that the stream service operates independently while maintaining consistent logging and security practices.

st2stream/st2stream · high confidence

Introduce structured logging configuration for console, file, and syslog outputs

Users can now configure logging for the st2api service via dedicated configuration files (console.conf, logging.conf, syslog.conf). This adds support for console-based logging, file-based logging using RotatingFileHandler, and syslog integration via ConfigurableSyslogHandler, allowing administrators to direct logs to appropriate destinations with specific formatters and log levels.

st2api/conf · high confidence

Introduced asynchronous callback mechanism for Mistral v2 runner

Added a new asynchronous callback implementation for the Mistral v2 runner, enabling the system to update action execution status in Mistral upon completion. This includes a base handler interface and a specific handler that maps internal action states to Mistral states, parses results, and updates the remote execution via the Mistral API.

_contrib/runners/mistral\v2/callback, st2common/st2common/callback · high confidence

Major overhaul of the st2 CLI client architecture

The st2 CLI client has been refactored to use a new, unified command structure. All commands now inherit from new base classes (Command, ResourceCommand, ResourceBranch) defined in st2client/commands, which standardize argument parsing, output formatting, and error handling. This change introduces a consistent interface for all CLI commands, including support for JSON/YAML output, attribute filtering, and improved error messages. Specific commands like 'st2 run', 'st2 execution', 'st2 pack', and 'st2 key' have been updated to use this new structure, resulting in better maintainability and a more predictable user experience.

st2client/st2client/commands · medium confidence

Migrate CI infrastructure from Travis to Circle CI

The project has switched its continuous integration provider from Travis to Circle CI. This change introduces a new set of shell scripts in the .circle directory to manage the test environment, including configuring RabbitMQ and PostgreSQL, installing and running MongoDB with specific performance and security flags (e.g., --notablescan), and setting up the 'stanley' user for SSH-based integration tests.

.circle · high confidence

Migrate v1 API controllers to the new v1 directory structure

The v1 API controllers for actions, action executions, action aliases, and API keys have been moved into the st2api/st2api/controllers/v1/ directory. This change reorganizes the codebase to better reflect the API versioning structure, ensuring that all v1 endpoints are co-located. The controllers now inherit from the updated base classes and utilize the new RBAC permission types for access control.

st2api/st2api/controllers/v1 · high confidence

Mistral v2 query module refactored with jitter and improved state handling

The Mistral v2 query module has been refactored to improve reliability and state mapping. A random jitter delay has been added to HTTP calls when fetching task results, helping to avoid request spikes. The mapping of workflow states has been updated to correctly map the 'CANCELLED' state to the corresponding live action status, and the system now allows the querier plugin to decide whether to delete the state object on error.

_contrib/runners/mistral\v2/query · medium confidence

New logging and test configuration files for the st2tests environment

Added new configuration files to the st2tests directory to support integration testing. This includes dedicated logging configurations for the API, authentication, and sensor container services, each directing logs to /tmp with timestamps. A main st2.conf file was added to define test environment settings, including API and auth host/port bindings, messaging queue URLs, and SSH runner parameters. Additionally, a cryptographic key file for KV store tests and an insecure Vagrant private key were added to support test infrastructure.

st2tests/conf · medium confidence

New logging configurations for reactor components

Added dedicated logging configuration files for the sensor container, rules engine, and garbage collector services. Each service now has its own console, file, and syslog logging setups, ensuring that logs are properly separated and formatted for each component.

st2reactor/conf · high confidence

Packaging and build infrastructure for st2common

The st2common package now includes a complete build and packaging system. A new Makefile provides targets for building RPM and DEB packages, generating wheel distributions, and managing versioning. The setup.py script is updated to dynamically parse requirements from in-requirements.txt and includes specific scripts such as st2ctl, st2-bootstrap-rmq, and migration tools. Additionally, a dist\_utils.py helper is added to manage requirements and apply a Vagrant-specific workaround, while MANIFEST.in and in-requirements.txt define the package contents and dependencies.

st2api, st2common · medium confidence

Re-organized st2tests pack fixtures

The st2tests pack fixtures have been reorganized. A new \_\init\\_.py file was added to the packs directory, and the 'core' directory is now a symlink pointing to the contrib/core directory, indicating a structural change in how test fixtures are organized.

st2tests/st2tests/fixtures/packs · medium confidence

Refactor API service entry point and setup logic

The st2api service entry point has been refactored into a new cmd/api.py module, which now handles the complete lifecycle: calling common\_setup (including database and message queue initialization), performing pre-runtime validation (such as RBAC configuration checks), and starting the WSGI server. This change consolidates the API service startup logic, ensuring consistent initialization and teardown procedures across the application.

st2api/st2api/cmd · medium confidence

Refactor action alias parsing and parameter handling into new utility modules

The \st2common\ package now includes new utility modules for action alias parsing and parameter handling. The \action\_alias\_utils\ module introduces a regex-based \ActionAliasFormatParser\ that supports both format strings and key=value pairs, allowing users to mix and match these parameter styles. The \action\_param\_utils\ module provides functions to cast action parameters, validate required fields, and merge runner/action parameter metadata. Additionally, \sensor\_type\_utils\ and \profiling\ modules are added to handle sensor type creation and MongoDB query profiling, respectively.

st2common/st2common/models/utils · high confidence

Refactor and enhance logging subsystem with secret masking and custom formatters

The logging module has been reorganized into a dedicated package (st2common/logging) containing filters, formatters, and handlers. Users will see improved debug logging, with the ability to mask sensitive parameters in log messages by default. The system now supports custom console and GELF log formatters, and log file names include a Unix timestamp. Additionally, log files are re-opened on the SIGUSR1 signal, and the --debug flag correctly sets all loggers to DEBUG level.

st2common/st2common/logging · medium confidence

Refactor runner container into new module structure

The runner container logic has been reorganized into a new module structure, with the base runner implementation moved to st2actions/container/base.py and the container service to st2actions/container/service.py. This change improves code organization and maintainability by separating the core runner container logic from the service interface, while maintaining the same functionality for executing and managing action runners.

st2actions/st2actions/container · high confidence

Refactor st2api to use OpenAPI router and WSGI middleware

The st2api service has been refactored to use an OpenAPI-based router instead of the previous Pecan-based routing. This change introduces WSGI middleware for error handling, CORS, logging, and request IDs, and moves common configuration options to st2api.config. The validation module now enforces that RBAC is only enabled when authentication is active, preventing misconfiguration. Additionally, the API now supports a configurable max\_page\_size for query strings.

st2api/st2api · medium confidence

Refactored and improved API middleware for logging, CORS, and error handling

The st2common middleware components have been restructured and enhanced. The CORS middleware now explicitly handles pre-flight OPTIONS requests and sets appropriate headers to prevent browser-side errors. The logging middleware has been updated to include the API response body in DEBUG-level logs, providing more context for debugging, while the error handling middleware was fixed to prevent traceback duplication and ensure consistent error responses. Additionally, the request ID middleware was added to ensure every request has a unique identifier for better tracking.

st2common/st2common/middleware · medium confidence

Refactored authentication backend loading and added base classes for capabilities

The st2auth backends module was refactored to use the stevedore library for dynamic backend loading, replacing the previous home-grown solution. This introduces a new base class, BaseAuthenticationBackend, which defines standard methods like authenticate, get\_user, and get\_user\_groups. Additionally, an AuthBackendCapability enum was added to define backend capabilities such as user authentication, user information, and group information.

st2auth/st2auth/backends · medium confidence

Refactored content registration into modular registrar classes

The content registration logic in st2common has been refactored into separate, reusable registrar classes (e.g., ActionsRegistrar, AliasesRegistrar, RulesRegistrar, etc.) that inherit from a common ResourceRegistrar base. This change improves consistency across resource types, enables better error handling with configurable failure modes (fail\_on\_failure), and supports pack-level registration. Users will see more consistent behavior when registering content, with improved error messages and the ability to control whether registration failures abort the entire process or continue with other resources.

st2common/st2common/bootstrap · high confidence

Refactored messaging transport layer with improved cluster resilience

The messaging transport in st2common has been refactored to improve reliability and cluster support. A new ConnectionRetryWrapper handles automatic reconnection and failover to alternate nodes in a RabbitMQ cluster, ensuring that connection drops do not cause message loss. The system now utilizes separate dispatcher pools for actions and workflows to prevent blocking, and introduces a staged message handling approach that acknowledges messages before processing, enhancing fault tolerance.

st2common/st2common/transport · high confidence

Refactored service entry points for action runner, notifier, and results tracker

The command-line entry points for the action runner, notifier, and results tracker have been refactored to use a common service setup and teardown module. This change standardizes how each service initializes, registers message queue exchanges, and handles signal processing, ensuring consistent behavior across all three components.

st2actions/st2actions/cmd · medium confidence

Refactored stream controller into dedicated module

The stream endpoint handler has been moved from the root controller into a dedicated \StreamController\ class in \st2stream/controllers/v1/stream.py\. This change isolates the server-sent events (SSE) logic, which formats and yields event data, into its own module, improving code organization and maintainability.

st2stream/st2stream/controllers · high confidence

Reimplement st2auth as an OpenAPI-based service

The st2auth service has been restructured to use an OpenAPI specification for routing, replacing the previous Pecan-based implementation. This change introduces a new middleware stack (ErrorHandling, Cors, Logging, RequestID) and updates the configuration options to support SSL, debug mode, and authentication backends. The service now validates the authentication backend configuration at startup, ensuring that if remote group synchronization is enabled, the configured backend exposes user group information. Additionally, the WSGI entry point has been updated to support Gunicorn deployment with environment variable configuration.

st2auth/st2auth · high confidence

Relocate runner infrastructure to st2common

The runner supporting infrastructure, including base classes, SSH and Windows runners, and the Python action wrapper, has been moved to the st2common package. This reorganization improves import efficiency and centralizes common runner logic, ensuring that remote command and script runners properly close SSH connections after action execution and handle non-JSON serializable results in the Python action wrapper.

st2common/st2common/runners · high confidence

Relocated garbage collection modules to st2common

The garbage collection modules for purging executions and trigger instances have been moved to the st2common package. This change removes the dependency of st2common on st2reactor, improving the module's independence. The purge functions now log the number of deleted objects and provide improved logging messages for better observability.

_st2common/st2common/garbage\collection · medium confidence

Reorganized test infrastructure with new base classes and fixtures

The test suite has been reorganized to improve consistency and maintainability. New base test classes (BaseActionTestCase, BaseSensorTestCase, BaseActionAliasTestCase) have been introduced to standardize how tests for actions, sensors, and aliases are structured. A FixturesLoader utility class was added to simplify loading test data into the database, and test fixtures were moved into a dedicated directory structure. Additionally, a custom TestApp wrapper was implemented to automatically validate API responses for security (secret leakage) and CORS headers.

st2tests/st2tests · high confidence

Restructured st2reactor module initialization

The st2reactor package initialization file has been emptied, indicating a structural refactoring where the module's initialization logic has been moved or consolidated elsewhere within the st2reactor directory.

st2reactor/st2reactor · medium confidence

Result tracker module moved to a separate package

The result tracker functionality has been reorganized into a dedicated \st2actions.resultstracker\ package, containing its own configuration and core logic. This structural change isolates the result tracking component, ensuring it has its own configuration options and logging setup, which improves modularity and maintainability of the actions service.

st2actions/st2actions/resultstracker · high confidence

Standardized logging configuration across st2actions components

The st2actions component now uses dedicated configuration files (console.conf, logging.conf, syslog.conf, and their .notifier and .resultstracker variants) to define logging behavior. This change introduces structured JSON-formatted audit logs for the main actions runner, configures GELF-formatted audit logs for the notifier and result tracker, and standardizes console and file logging formats. Users will see more consistent and detailed log output, with specific handlers for console, file, and syslog destinations, each with appropriate log levels and formatters.

st2actions/conf · medium confidence

Timer implementation refactored with APScheduler integration

The timer subsystem has been refactored to use APScheduler 3.0 for managing scheduled jobs, replacing the previous internal scheduling mechanism. This change introduces a new base implementation for timer handling, which now validates trigger parameters using the shared schema validation utilities. The timer logic is now decoupled from sensor functionality, and the system now supports exclusive queues for timer triggers to prevent race conditions. Additionally, trace tags are now meaningfully associated with timer executions, and the codebase has been updated to handle default None values for attributes regardless of their type.

st2reactor/st2reactor/timer · medium confidence

The index page template has been updated to display the StackStorm version and a link to the documentation. Previously, the index page might have been broken or missing, but now it correctly shows the version number and a link to the StackStorm documentation.

st2api/st2api/templates · medium confidence

Updated dummy pack fixtures with valid structure and content

The test fixtures for dummy packs 2 and 3 have been reorganized and populated with valid content. Each pack now includes a properly defined action (my\_action.py and my\_action.yml) and a sensor file, ensuring that validation does not fail. Additionally, a policy file (policy\_3.yaml) was added to the dummy\_pack\_2 fixtures to support test cases.

_st2tests/st2tests/fixtures/packs/dummy\_pack\2 · medium confidence

Updated dummy\_pack\_1 fixture with valid configuration schema

The dummy\_pack\_1 test fixture has been reorganized and updated to include a valid configuration schema (config.schema.yaml) that defines required string fields for api\_key, api\_secret, and region. This ensures that pack validation does not fail during testing, and the pack metadata (pack.yaml) is also included to support the test environment.

_st2tests/st2tests/fixtures/packs/dummy\_pack\1 · medium confidence

Fixes

Added empty \_\_init\_\_.py to st2tests/fixtures

An empty \_\init\\_.py file was added to the st2tests/fixtures directory, marking it as a Python package.

st2tests/st2tests/fixtures · high confidence

Empty bootstrap modules added for st2actions and st2reactor

Empty \_\init\\_.py files were added to the st2actions/st2actions/bootstrap and st2reactor/st2reactor/bootstrap directories. This creates the necessary package structure for content registration in these components.

st2actions/st2actions/bootstrap, st2reactor/st2reactor/bootstrap · medium confidence

Test coverage

Add local runner test fixture for text generation; Add sample sensor fixture for testing sensor enable/disable; Add test fixtures for pack validation and error handling; Add test harness for policy application logic; Added Python action test resources for edge cases; Added SSH runner integration tests; Added SSH test resources for paramiko testing; Added Twilio integration pack test fixtures; Added empty \_\init\\.py files for integration test directories; Added empty \\init\\.py files to establish test package structure; Added empty test module for st2common; Added empty test package for st2actions; Added execution test fixtures for actions, runners, and triggers; Added htpasswd test fixture; Added integration test fixtures for st2api and st2sensorcontainer logs; Added integration tests for Gunicorn configurations; Added integration tests for Mistral workflow execution and error handling; Added integration tests for action state consumer, notifier, results tracker, and Python runner wrapper; Added integration tests for garbage collector, rules engine, and sensor container; Added integration tests for the debug info submission tool; Added integration tests for the export worker and dumper; Added integration tests for the st2-register-content script; Added mock runner and callback fixtures for testing; Added test base class for CLI unit tests; Added test configuration fixtures for Mistral and st2; Added test coverage for pack management actions; Added test fixtures and mock sensor classes for resource testing; Added test fixtures for action runners; Added test fixtures for execution and CLI configuration; Added test infrastructure for st2auth; Added test logging configuration for audit support; Added test resources for loadable plugin tests; Added tests for UUID generation action; Added tests for chatops execution result formatting; Added tests/\\init\\_.py; Added unit tests for action policies; Added unit tests for auth backends, handlers, and validation utilities; Added unit tests for core services; Added unit tests for st2client CLI components; Added unit tests for st2reactor components; Added unit tests for system info utilities; Added unit tests for the Mistral v2 runner; Added unit tests for the Mistral workflow validation endpoint; Added unit tests for the PrimeCheckerAction; Added unit tests for the action chain runner; Added unit tests for the dumper and JSON converter components; Added unit tests for the stream controller; Added unit tests for the v1 token controller; Added unit tests for v1 API controllers; Added unit tests for validation utilities; Expanded action fixture library for testing edge cases; Expanded unit test coverage for st2actions; Initialize test package for st2reactor; Migrate history view fixtures from JSON to YAML; New test base classes for API and RBAC testing; Organized unit tests into a dedicated directory structure; Unit tests added for HTTP runner client.

Dependencies

Pack-specific dependency manifests introduced

Individual packs (examples, hello\_st2, linux, twilio, dummy\_pack\_2, pack\_invalid\_requirements) and client components now include their own requirements.txt files. This isolates each pack's Python dependencies from the global requirements, allowing for more granular dependency management and ensuring that each pack declares only the libraries it actually needs.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

How this codebase got here

Score

  • CAI 38 → 47 (+9.2)
  • Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

Lenses

  • Code Health 83 → 88 (+5.4)
  • Architecture 96 → 90 (-5.6)
  • Maturity 51 → 50 (-0.2)
  • Readiness 18 → 30 (+11.7)
  • Security 45 → 65 (+19.9)

Resolved (54)

  • Boundary-crossing change coupling: action_chain_runner.py ↔ datatransform.py (contrib/runners/action_chain_runner/action_chain_runner.py)
  • Change coupling: action.py ↔ rule.py (st2common/st2common/models/db/action.py)
  • ConcurrencyByAttributePolicyTest.test_on_cancellation (cognitive 16) (st2actions/tests/unit/policies/test_concurrency_by_attr.py)
  • ConcurrencyByAttributePolicyTest.test_over_threshold_delay_executions (cognitive 16) (st2actions/tests/unit/policies/test_concurrency_by_attr.py)
  • Coverage not included — suite not readable by the collector
  • Critical CVE: [GHSA redacted] (fixed-requirements.txt)
  • Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
  • Duplicated block (10 lines × 2) (st2actions/st2actions/notifier/notifier.py)
  • Duplicated block (10 lines × 2) (st2api/st2api/controllers/v1/actionalias.py)
  • Duplicated block (10 lines × 2) (st2client/st2client/commands/resource.py)
  • Duplicated block (10 lines × 2) (st2client/st2client/utils/interactive.py)
  • Duplicated block (10 lines × 2) (st2common/st2common/services/sensor_watcher.py)
  • Duplicated block (11 lines × 2) (st2client/st2client/commands/auth.py)
  • Duplicated block (11 lines × 2) (st2client/st2client/commands/rbac.py)
  • Duplicated block (11 lines × 2) (st2client/st2client/commands/resource.py)
  • Duplicated block (11 lines × 2) (st2client/st2client/commands/rule_enforcement.py)
  • Duplicated block (11 lines × 2) (st2common/st2common/persistence/base.py)
  • Duplicated block (11 lines × 2) (tools/diff-db-disk.py)
  • Duplicated block (12 lines × 2) (st2common/st2common/bootstrap/sensorsregistrar.py)
  • Duplicated block (12 lines × 2) (st2common/st2common/bootstrap/sensorsregistrar.py)
  • …and 34 more

New (215)

  • Change coupling: actionsregistrar.py ↔ rulesregistrar.py (st2common/st2common/bootstrap/actionsregistrar.py)
  • Change coupling: remote_command_runner.py ↔ remote_script_runner.py (contrib/runners/remote_command_runner/remote_command_runner.py)
  • Change coupling: st2notifier.py ↔ st2resultstracker.py (st2actions/st2actions/cmd/st2notifier.py)
  • Change coupling: windows_command_runner.py ↔ windows_script_runner.py (contrib/runners/windows_command_runner/windows_command_runner.py)
  • Critical CVE: [GHSA redacted] (fixed-requirements.txt)
  • Documentation: no architecture or design documentation (README.md)
  • Documentation: no installation or build instructions (README.md)
  • Duplicated block (10 lines × 2) (st2actions/st2actions/cmd/st2resultstracker.py)
  • Duplicated block (10 lines × 2) (st2api/st2api/cmd/api.py)
  • Duplicated block (10 lines × 2) (st2api/st2api/controllers/v1/actionalias.py)
  • Duplicated block (10 lines × 2) (st2client/st2client/commands/pack.py)
  • Duplicated block (10 lines × 2) (st2client/st2client/commands/resource.py)
  • Duplicated block (10 lines × 2) (st2common/st2common/services/sensor_watcher.py)
  • Duplicated block (10 lines × 4) (st2client/st2client/commands/rbac.py)
  • Duplicated block (10 lines × 5) (st2actions/st2actions/cmd/actionrunner.py)
  • Duplicated block (11 lines × 2) (st2actions/st2actions/notifier/notifier.py)
  • Duplicated block (11 lines × 2) (tools/diff-db-disk.py)
  • Duplicated block (11 lines × 5) (st2client/st2client/commands/resource.py)
  • Duplicated block (12 lines × 2) (st2client/st2client/utils/interactive.py)
  • Duplicated block (12 lines × 2) (st2common/st2common/bootstrap/sensorsregistrar.py)
  • …and 195 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

Survey your own repository

jpsuldo1/st2 was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.

About this page

  • The score is its most recent published measurement, taken on 22 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
  • Measured at commit 1527076de1917a7d4eef52372e675d32c7f51548 — the exact code this score is about.
  • Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
  • Measured by watchdog.canine.dev using codehealth-analyzer preprod-821afab8930d.