sh1nu11b1/st2
47.3
Weak · 22 September 2026
58.1k
lines of production code
Python
primary language
5
measurements over time
What this system is
This system is an open-source automation platform that orchestrates and executes remote commands, scripts, and workflows across diverse environments. It provides a unified interface to manage the full lifecycle of content packs, enforce concurrency and retry policies, and handle event-driven rule processing. The architecture is modular, separating concerns into distinct services for API, authentication, streaming, and background job execution, all supported by a comprehensive CLI and testing infrastructure.
How it got here
2014 — Modularization and packaging infrastructure
94 changes.
This period focused on restructuring the codebase into distinct, modular components such as st2api, st2auth, and st2reactor, each with dedicated build and packaging infrastructure. The work established a standardized foundation for the platform by introducing RBAC, a new message transport layer, and a CLI client, while significantly expanding test coverage and utility modules.
2015 — RBAC, debugging, and exporter features
56 changes.
This period focused on introducing Role-Based Access Control (RBAC) to secure API endpoints and implementing a new debug information submission tool with sensitive data redaction. The team also launched the st2exporter package for persisting execution data and added comprehensive integration tests for these new features alongside existing components like the garbage collector and chatops actions.
2016–2017 — runner infrastructure and remote execution
44 changes.
This period focused on establishing a robust, unified runner infrastructure within the st2common package, enabling the execution of actions across diverse platforms including Linux, Windows, and remote hosts via SSH. The work introduced a comprehensive suite of new runners—such as HTTP, Python, Mistral, and local shell execution—alongside the necessary packaging, configuration, and test coverage to support them.
Features
Add Linux system administration actions
Introduces a new set of Linux pack actions for system administration, 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 enable users to monitor system load and processes, manage files and directories, perform network diagnostics, and manage services on remote Linux hosts.
contrib/linux/actions · high confidence
Add Mistral v2 runner for executing workflows
A new Mistral v2 runner has been added to the system, enabling the execution of Mistral v2 workflows. This includes the core runner implementation and its configuration file, allowing users to run workflows via the Mistral v2 interface.
_contrib/runners/mistral\v2 · high confidence
Add Mistral workflow validation
Users can now validate Mistral workbook and workflow definitions. A new base validator class and a specific Mistral v2 implementation have been added to the workflow validation system, enabling the platform to check the correctness of Mistral-based automation workflows before execution.
st2common/st2common/validators/workflow · high confidence
Add NoopRunner for static, parameterless actions
A new 'noop' runner has been added to the system, allowing users to execute actions that return a static success response regardless of input parameters. The implementation includes the Python runner class, its YAML configuration, and a comprehensive set of unit and integration tests to verify the behavior.
_contrib/runners/noop\runner · high confidence
Add Pylint plugins for API and database model type inference
New Pylint plugins have been added to improve static analysis for dynamically typed classes. The \api\_models\ plugin teaches Pylint to infer property types from JSON Schema definitions, correctly mapping types such as object, array, integer, number, string, boolean, and null, while also normalizing property names by replacing dashes with underscores. The \db\_models\ plugin informs Pylint about the implicit 'id' field on MongoEngine document classes. These changes reduce false-positive linting errors for these specific model patterns.
_pylint\plugins · high confidence
Add Python action examples for data parsing and iteration
Added a suite of example Python actions to the st2 framework, including scripts for parsing JSON and YAML strings, checking for prime numbers, generating Fibonacci sequences, and iterating through GitHub repository data. These new examples demonstrate how to implement and use Python-based actions for common data processing and API interaction tasks.
contrib/examples/actions/pythonactions · high confidence
Add Stream API entry point
The st2stream service now includes a new command-line entry point (st2stream/cmd/api.py) that initializes the Stream API server using eventlet and WSGI. This change introduces the main execution path for the Stream component, handling setup, graceful shutdown, and signal handling for long-running stream requests.
st2stream/st2stream/cmd · high confidence
Add Windows PowerShell script to display system uptime
A new PowerShell script named 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.
contrib/examples/actions/windows · high confidence
Add Windows Script Runner for remote PowerShell execution
A new Windows Script Runner has been added to the system, enabling the execution of remote PowerShell scripts on Windows hosts. This feature introduces a new runner type that accepts parameters such as host, username, password, and timeout, allowing users to upload and execute scripts on remote Windows machines via the st2common infrastructure.
_contrib/runners/windows\_script\runner · high confidence
Add configuration files and entry point for the ST2 exporter
The exporter now includes a Python entry-point script (st2exporter/bin/st2exporter) and three configuration files: logging.exporter.conf for general logging, st2exporter.dev.conf for development settings (including AMQP messaging and logging exclusions), and syslog.exporter.conf for syslog-based logging. These changes enable the exporter to run and configure its logging and messaging behavior.
st2exporter/conf · high confidence
Add configuration files for st2auth deployment and logging
New configuration files are introduced to support the st2auth service. An Apache sample configuration enables WSGI deployment with SSL and external authentication via pwauth. Logging is configured across multiple backends: a console handler for development, a rotating file handler for general logs, a GELF formatter for audit logs, and a configurable syslog handler for system log integration.
st2auth/conf · high confidence
Add entry point for the StackStorm exporter binary
Users can now run the exporter as a standalone binary. The new \st2exporter\_starter.py\ module provides the \main\ entry point, which initializes the StackStorm service setup, applies monkey patches, and starts the background worker to handle export tasks.
st2exporter/st2exporter/cmd · high confidence
Add example sensor templates for st2
Added new example sensor templates in the contrib/examples/sensors directory, including sample\_polling\_sensor.py, sample\_sensor.py, and their corresponding YAML metadata files. These serve as reference implementations for creating custom sensors, demonstrating how to implement the Sensor and PollingSensor base classes, use the sensor\_service for logging and dispatching triggers, and define trigger types with payload schemas.
contrib/examples/sensors · high confidence
Add executable entry points for action runner, notifier, and result tracker
New executable scripts are now available in the st2actions/bin directory: st2actionrunner, st2notifier, and st2resultstracker. These Python-based entry points allow users to directly invoke the action runner, notifier, and result tracker components. Additionally, the runners.sh script has been updated to support multiple init systems (systemd, upstart, and sysv) and includes fixes for Debian container environments.
st2actions/bin · medium confidence
Add execution export worker and configuration
Introduces a new \ExecutionsExporter\ worker that consumes execution events from the message queue and persists them to a configurable dump directory. The worker bootstraps by querying the database for missed executions, converts them to the API model with secret masking, and queues them for the dumper. Configuration is centralized in \config.py\ with options for the dump directory and logging.
st2exporter/st2exporter · high confidence
Add experimental Mistral workflow validation endpoint
An experimental API endpoint for validating Mistral workflow definitions has been added. Users can now POST workflow definitions to this new validation controller, which leverages the existing Mistral validation utilities to check for errors and return structured validation results.
st2api/st2api/controllers/exp · high confidence
Add extensive Mistral workflow examples and ActionChain templates
The examples pack now includes a large set of new Mistral workflow definitions and ActionChain templates. These cover common workflow patterns such as branching, joining parallel branches, error handling, retry logic, and cancellation. The examples also demonstrate the use of Jinja filters for data processing, access to system and user key-value pairs, and various parameter types. This provides users with ready-to-use templates for building complex workflows in StackStorm.
contrib/examples/actions · high confidence
Add file dumper and exporter components for exporting execution data
Introduced new modules in the exporter package to handle the persistence of execution data. The \Dumper\ class manages the background processing of execution items from a queue, writing them to disk as JSON files. It organizes output into date-based subdirectories and persists a database marker to track the last successfully exported timestamp. Supporting components include a \TextFileWriter\ for file I/O and a \JsonConverter\ for serializing data, enabling the system to reliably export execution records to the filesystem.
st2exporter/st2exporter/exporter · high confidence
Add green shell utility for non-blocking command execution
A new 'green' utility package has been introduced in st2common, providing a 'run\_command' function that executes shell commands using eventlet's green subprocess implementation. This allows commands to run without blocking the event loop, and supports custom pre-execution and kill functions to handle timeouts and process management more flexibly.
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, providing a complete set of sample components for StackStorm. This includes a Python sensor that periodically emits a custom event, a shell-based action that greets users, a rule to trigger the action on the sensor's event, and associated policies and aliases. This serves as a reference implementation for building custom packs.
_contrib/hello\st2 · high confidence
Add initial Nginx configuration for StackStorm services
A new Nginx configuration file (st2.conf) is introduced to manage traffic for the StackStorm web UI, API, authentication, and streaming endpoints. The configuration sets up HTTP-to-HTTPS redirection, SSL termination, and reverse proxy rules for /api/, /auth/, and /stream/ paths, including specific error handling for 502/503 states and performance optimizations like sendfile and TCP flags.
conf/nginx · high confidence
Add remote script runner with SSH and passphrase support
A new remote script runner has been introduced, allowing actions to be executed on remote hosts via SSH. The implementation includes a \passphrase\ parameter in the runner configuration, enabling the use of password-protected private SSH keys. The runner also supports copying local scripts and associated libraries to the remote host, executing the script, and cleaning up the remote directory afterward.
_contrib/runners/remote\_script\runner · high confidence
Add send\_mail action with attachment and content-type support
A new send\_mail action script is introduced to the core actions, enabling the sending of emails with support for multiple recipients, custom subjects, and local file attachments. The script validates the presence of the sendmail binary, constructs multipart MIME messages with appropriate content types, and handles empty body scenarios. It also appends a footer containing the hostname and script name to the email body.
_contrib/core/actions/send\mail · high confidence
Add shell autocomplete script for st2 client
A new shell completion script (st2.complete.sh) is added to the st2client configuration directory. This script enables command-line autocomplete for the st2 client, allowing users to press the Tab key to auto-complete st2 commands and arguments in supported shells.
st2client/conf · high confidence
Add st2stream executable entry point
Users can now run the st2stream command directly from the command line, which invokes the main entry point for the st2stream application.
st2stream/bin · high confidence
Add token validation and authentication endpoints to the v1 API
The st2auth service now exposes a new v1 API for token management. Users can validate existing tokens via a dedicated validation endpoint and obtain new tokens through the authentication controller, which supports proxy and standalone authentication modes. This change introduces the necessary controllers and routing to support these operations, replacing the previous implementation with a more modular structure.
st2auth/st2auth/controllers/v1 · medium confidence
Added StackStorm lint configuration files
Added a new 'lint-configs' directory containing shared linting configurations for Python tools, including .flake8 and .pylintrc files. These files provide standardized linting rules for Python projects within the StackStorm ecosystem, allowing developers to easily integrate consistent code quality checks.
lint-configs · high confidence
Added Windows command runner for remote execution
Introduced a new Windows command runner that enables executing arbitrary commands on remote Windows hosts. The change adds the \windows\_command\_runner\ module, its \runner.yaml\ manifest, and associated unit and integration tests, allowing users to run commands on Windows machines via the \winexe\ and \smbclient\ utilities.
_contrib/runners/windows\_command\runner · high confidence
Added build and packaging infrastructure for st2reactor
Introduced new build and packaging infrastructure for the st2reactor component, including a Makefile with targets for RPM and DEB package generation, a setup.py for Python distribution, and supporting files like MANIFEST.in, setup.cfg, and dist\_utils.py. This enables the component to be built into installable packages and wheels, with support for both Debian and Red Hat-based systems.
st2reactor · medium confidence
Added local shell runner for executing local commands and scripts
The local runner has been implemented to execute local shell commands and scripts. This new component allows the system to run arbitrary Linux commands or scripts on the host machine, supporting features such as sudo execution, environment variable passing, working directory specification, and configurable timeouts. The implementation includes the core runner logic, a YAML configuration file defining the runner's parameters, and a comprehensive suite of integration and unit tests to verify correct behavior, including handling of timeouts and process termination.
_contrib/runners/local\runner · high confidence
Added new Bash example actions for exit codes, pinging, and random number generation
New example scripts have been added to demonstrate basic Bash functionality. The bash\_exit\_code action now provides a script that generates and exits with a random exit code. The bash\_ping action includes a script that accepts a count parameter (defaulting to 3) to control the number of ping attempts. Additionally, the bash\_random action now offers two scripts: one that generates a single random number, and another that generates a specified number of random values in a loop.
_contrib/examples/actions/bash\_exit\_code, contrib/examples/actions/bash\_ping, contrib/examples/actions/bash\random · high confidence
Added packaging metadata and build infrastructure for st2stream
The st2stream component now includes standard Python packaging files (setup.py, MANIFEST.in, dist\_utils.py) and build scripts (Makefile) to support wheel and RPM/DEB package generation. This enables the stream service to be built and installed as a distributable Python package, including handling of requirements and Vagrant-specific workarounds during distribution.
st2stream · high confidence
Added sample configuration files for high availability setup
New sample configuration files have been added to support a high availability deployment of StackStorm. This includes an \st2.conf.sample\ for the application settings, along with \st2.conf.blueprint.sample\ and \st2.conf.controller.sample\ for Nginx reverse-proxy configurations. These templates provide the necessary settings for API, authentication, messaging, and database connections, as well as Nginx server blocks for SSL termination and load balancing across multiple nodes.
conf/HA · high confidence
Added st2auth executable entry point
A new executable script has been added at st2auth/bin/st2auth, which serves as the command-line entry point for the st2auth service. This script invokes the main function from st2auth.cmd.api, enabling users to run the authentication service directly from the command line.
st2auth/bin · high confidence
Automated CI/CD pipeline for Mistral integration tests
The CI/CD pipeline now includes a dedicated 'mistral' task that automatically provisions a Mistral environment, selects the appropriate branch based on the current release, and runs integration tests. This ensures that changes to the Mistral integration are validated on every commit.
scripts/travis · high confidence
Expanded Mistral workflow examples for testing and usage
Added a comprehensive set of new Mistral workflow examples in the contrib/examples/actions/workflows directory. These include templates for basic tasks, branching, environment variables, error handling, retry logic, cancellation, and subworkflow execution. The collection also introduces Jinja2-based workflow definitions alongside existing YAQL examples, providing users with diverse patterns for workflow design, error management, and concurrency control.
contrib/examples/actions/workflows · high confidence
Initial packaging and distribution setup for st2client
The st2client package is now fully packaged for distribution, including a setup.py configuration, a LICENSE file (Apache 2.0), and a MANIFEST.in to ensure all necessary files are included in source distributions. The build system has been standardized on setuptools, with a Makefile providing targets for building RPM and DEB packages, as well as Python wheels. Dependencies are explicitly listed in setup.py and in-requirements.txt, and a dist\_utils.py helper is provided to manage requirements and handle environment-specific workarounds.
st2client · high confidence
Initial release of st2exporter package
The st2exporter component is now packaged as a standalone Python package, enabling independent distribution and installation. This includes a setup.py configuration, a Makefile for building wheels and handling dependencies, and utility scripts to manage requirements and build artifacts.
st2exporter · high confidence
Introduce Action Chain Runner for linear workflows
A new action-chain runner is added to the system, enabling the execution of linear action chains where tasks are executed sequentially based on success or failure conditions. The runner includes a \display\_published\ parameter (defaulting to \True\) to control the visibility of intermediate published variables, and supports skipping notifications for specific tasks via the \skip\_notify\ parameter.
_contrib/runners/action\_chain\runner · high confidence
Introduce HTTP runner with basic authentication support
Users can now execute HTTP actions using the new HTTP runner, which supports basic authentication via username and password parameters, along with headers, cookies, proxy settings, and SSL verification options.
_contrib/runners/http\runner · high confidence
Introduce Python script runner for executing Python-based actions
A new Python script runner is added to the system, enabling the execution of Python-based actions. The runner accepts environment variables and a configurable timeout (defaulting to 600 seconds) and handles the serialization and deserialization of action results, including robust error handling for non-serializable types.
_contrib/runners/python\runner · high confidence
Introduce RBAC (Role-Based Access Control) framework for resource permissions
The RBAC module has been added to the codebase, introducing a comprehensive permission system for managing access control. This includes a loader for reading role definitions and user assignments from disk, a syncer to synchronize these definitions with the database, and a set of permission resolvers that enforce access checks across various resource types such as actions, rules, webhooks, and executions. The implementation also provides utility functions to assert user permissions and check for system administrator roles, effectively placing an RBAC wall around API endpoints to restrict access based on defined roles and permissions.
st2common/st2common/rbac · high confidence
Introduce RBAC configuration and database setup infrastructure
The st2common package now includes new modules for database setup (database\_setup.py) and a comprehensive configuration file (config.py) that registers options for RBAC (including enable and sync\_remote\_groups flags), system user settings, schema versions, system debug mode, content pack paths, database connection details (including SSL support), messaging, syslog, and logging configurations. Additionally, a new ComplexDateTimeField is introduced to handle datetime storage in MongoDB using microseconds since the epoch, and the logging module is enhanced with an audit level and exclusion filters. The router module is also updated to support multiple specs.
st2common/st2common · high confidence
Introduce base REST controller classes and root endpoint
Adds new base classes for REST controllers in st2api, including a RootController that returns the StackStorm version and documentation URL at the root path. Introduces a BaseRestControllerMixin for common query parameter parsing and a ResourceController base class that standardizes list retrieval, sorting, pagination, and field exclusion across API endpoints.
st2api/st2api/controllers · high confidence
Introduce base model classes for serialization and secret masking
A new base model module is introduced in st2common/models, providing a DictSerializableClassMixin that enables objects to be serialized into dictionaries and supports masking sensitive values. This change establishes a foundational abstraction for model serialization across the application, allowing components to safely convert objects to JSON-serializable dictionaries while optionally hiding secrets.
st2common/st2common/models · high confidence
Introduce base policy applicator and concurrency policy support
Added a new policy framework in st2common/policies, introducing a base ResourcePolicyApplicator class that supports before/after execution hooks and a new concurrency policy implementation that can delay or cancel actions based on a configurable threshold. The change also includes a dynamic driver loading mechanism that safely instantiates policy classes from modules.
st2common/st2common/policies · high confidence
Introduce build and packaging infrastructure for st2auth
The st2auth component now includes a complete build system to support packaging and distribution. This adds a Makefile with targets for building RPM, DEB, and wheel packages, alongside a MANIFEST.in file to control source distribution contents. A new dist\_utils.py module provides shared utilities for parsing requirements and handling environment-specific workarounds, while setup.py is configured to explicitly define the package name and version. Additionally, an in-requirements.txt file lists the component's dependencies, including bcrypt, eventlet, and gunicorn, ensuring consistent dependency resolution during the build process.
st2auth · high confidence
Introduce configurable garbage collection service
A new garbage collector service has been added to automatically purge old data from the database. Users can now configure the collection interval and set the time-to-live (TTL) in days for action executions and trigger instances. The service also supports manual triggering via the SIGUSR2 signal.
_st2reactor/st2reactor/garbage\collector · medium confidence
Introduce debug information submission tool with sensitive data redaction
A new debug tool is introduced to collect and submit system information. The tool includes a script (st2-submit-debug-info) and supporting modules that process configuration files from StackStorm and Mistral, specifically redacting sensitive credentials and removing config.yaml from content packs before submission. The implementation uses a GPG public key for encryption and uploads to a specific S3 bucket (st2debuginfo.s3.amazonaws.com).
st2debug/st2debug · high confidence
Introduce dedicated logging configuration files for the Stream service
The Stream service now uses separate logging configuration files (console, file, and syslog) located in st2stream/conf/. This change allows administrators to configure logging for the Stream component independently from the rest of the system, supporting distinct log levels, handlers, and formatters for console output, rotating file logs, and syslog integration.
st2stream/st2stream · high confidence
Introduce mock implementations for testing
Added new mock classes for pack testing, including MockActionService, MockDatastoreService, MockActionRunner, MockSensorService, and publishers for execution and live action events. These utilities allow developers to run unit tests without requiring a live backend, providing controlled environments for validating sensor, runner, and action logic.
st2tests/st2tests/mocks · high confidence
Introduce new API and DB models for core system entities
A new \st2common/st2common/models/api\ package has been introduced, containing API and database models for key system components including Actions, LiveActions, Runners, Auth/ApiKey, Executions, Key-Value pairs, Notifications, Packs, Policies, and base classes. This establishes the data structures used by the REST API layer to represent and validate these entities.
st2common/st2common/models/api · high confidence
Introduce process-based sensor container with hash partitioning
The sensor container now runs each sensor in a separate process, managed by a new \ProcessSensorContainer\ and \SensorWrapper\ classes. This change improves robustness by isolating sensor execution and includes automatic respawning of dead sensor processes. Additionally, a new hash-based partitioning system allows distributing sensors across multiple nodes, with the \HashPartitioner\ implementing a consistent hashing algorithm to determine which node runs which sensors. The \SensorContainerManager\ now handles sensor lifecycle events (create, update, delete) to dynamically add, reload, or remove sensors from the active set.
st2reactor/st2reactor/container · high confidence
Introduce remote command runner with configurable working directory
Added the remote command runner (remote-shell-cmd) which allows executing arbitrary Linux commands on remote hosts via SSH. This runner now supports configurable working directories for both the local execution environment and the remote host, with the default working directory for both 'cwd' and 'dir' parameters set to '/tmp'.
_contrib/runners/remote\_command\runner · high confidence
Introduce st2-debug tool for collecting and submitting debug information
Added a new \st2-debug\ utility that collects system, configuration, and log data into a tarball for debugging purposes. The tool supports encrypting the archive with GPG and uploading it to a specified S3 bucket. Users can customize which logs, configs, and content packs to include, and optionally provide user context (name, email, comment) when submitting debug info. The tool also handles cleanup of temporary files and ensures robust error handling for permissions and missing dependencies.
st2debug/st2debug/cmd · high confidence
Introduce st2api component with packaging and build infrastructure
The st2api component is introduced with a new build and packaging structure. A Makefile is added to handle RPM, DEB, and wheelhouse builds, alongside a setup.py script that defines the package metadata and dependencies. The component includes a MANIFEST.in to specify included files, a dist\_utils.py module for shared distribution utilities, and an in-requirements.txt file listing implicit dependencies like eventlet, mongoengine, and gunicorn. This establishes the foundational build and packaging configuration for the st2api service.
st2api · high confidence
Introduce st2auth command-line interface
A new command-line interface for the st2auth service has been added, enabling users to start the authentication API server directly. This includes support for configuring the host, port, and SSL/TLS settings (via the \use\_ssl\ option), with validation ensuring that certificate and key files exist when SSL is enabled. The entry point also handles common service setup and teardown, ensuring consistent logging and exception handling.
st2auth/st2auth/cmd · high confidence
Introduce st2client models for CLI resource mapping
The st2client package now includes a comprehensive set of Python models in the \st2client/models\ directory, providing the data structures required for the CLI to interact with the StackStorm API. This includes a base \Resource\ class in \core.py\ and specific model classes for actions, executions, triggers, policies, RBAC roles, and other domain entities. These models define the schema for API responses and requests, enabling the CLI to parse and display resource data effectively.
st2client/st2client/models · high confidence
Introduce st2client utility modules for CLI enhancements
Added a new st2client/utils package containing utility modules for the CLI: color formatting for status messages, date/time parsing and formatting with user timezone support, an HTTP client wrapper with SSL verification and auth token handling, interactive dialog readers for string/boolean/number inputs, JSON path extraction, logging level control, dictionary merging, string unescaping, and terminal size detection. These utilities enable colored CLI output, human-friendly timestamp display, interactive configuration prompts, and debug logging of cURL requests.
st2client/st2client/utils · high confidence
Introduce structured CLI formatters for JSON, YAML, and table output
The CLI now supports structured output formats (JSON and YAML) alongside the existing table view. This change introduces a new formatting system that allows users to request data in different formats, with specific formatters for execution results, documents, and multi-column tables. The table formatter has been updated to dynamically adjust column widths based on terminal size and handle edge cases like empty results or missing attributes more robustly.
st2client/st2client/formatters · high confidence
Introduce the new RulesEngine for processing trigger instances
The rules engine has been refactored into a new, dedicated component located in st2reactor/st2reactor/rules. This change introduces a new RulesEngine that handles trigger instances, utilizing separate classes for matching (RulesMatcher), filtering (RuleFilter), and enforcement (RuleEnforcer). The engine now listens to the trigger\_instances\_queue to process incoming triggers, creating RuleEnforcement records and invoking actions based on rule criteria. Configuration for the rules engine is now separated into its own config module, and the system now supports testing rules via a dedicated RuleTester.
st2reactor/st2reactor/rules · high confidence
Introduce the st2 Python CLI client
The st2 Python CLI client is introduced, providing a command-line interface for interacting with the StackStorm API. This includes a new base class for CLI applications, a client class that manages API endpoints and resource managers, and a shell entry point that registers commands for actions, triggers, policies, and more. The client supports configuration via a config file, environment variables, and command-line arguments, with features like token caching, debug mode, and SSL certificate verification.
st2client/st2client · high confidence
Introduces a structured exception hierarchy for StackStorm components
A new \st2common/st2common/exceptions\ package is introduced, establishing a structured exception hierarchy for the StackStorm server. This includes a base \StackStormBaseException\ and a plugin-specific \StackStormPluginException\, along with specialized exceptions for actions, action runners, API validation, authentication, database operations, RBAC, and other subsystems. This change improves error handling and debugging by providing specific exception types for different failure scenarios, such as \TokenNotFoundError\, \AccessDeniedError\, and \ActionRunnerException\.
st2common/st2common/exceptions · high confidence
Introduces new sensor base classes and configuration structure
Adds new base classes for sensors, including an abstract \BaseSensor\ with \setup\, \run\, and \cleanup\ methods, as well as specific \Sensor\ and \PollingSensor\ implementations. The \PollingSensor\ introduces a configurable \poll\_interval\ and a \poll\ method for active sensors. Additionally, a new \config.py\ file registers sensor container options, including logging and partition provider settings, under the \sensorcontainer\ configuration group.
st2reactor/st2reactor/sensor · high confidence
New CLI entry points for reactor components
Added new command-line entry points for the StackStorm reactor subsystem, including st2-rule-tester, st2-trigger-refire, st2garbagecollector, st2rulesengine, and st2sensorcontainer. These scripts provide direct access to the underlying Python modules for testing rules, refiring triggers, and managing sensors and the rules engine.
st2reactor/bin · high confidence
New CLI utilities for config validation, API spec generation, and execution purging
Added new command-line tools to the st2common package: a script to validate configuration files against a schema, a script to generate the OpenAPI specification, and utility scripts to purge old executions and trigger instances. These new commands provide users with dedicated tools to verify their configuration files, generate API documentation, and perform garbage collection of historical data.
st2common/st2common/cmd · high confidence
New ChatOps actions for matching, executing, and formatting results
Added new ChatOps pack actions to the contrib directory: \format\_execution\_result\ for rendering execution results using Jinja2 templates, \match\ for identifying action aliases from text, \match\_and\_execute\ to match and run commands while waiting for completion, and workflow-based actions \run\ and \post\_result\ for executing commands and posting results to chat streams. These changes introduce new capabilities for interacting with the chat interface, including template-based formatting and direct execution workflows.
contrib/chatops/actions · high confidence
New Jinja2 filters for data, regex, time, and versioning
Adds a suite of new Jinja2 filters to the st2common module, enabling users to manipulate data and format output directly in templates. This includes \to\_json\_string\ and \to\_yaml\_string\ for serialization, \json\_escape\ for safe string escaping, and regex helpers (\regex\_match\, \regex\_replace\, \regex\_search\, \regex\_substring\) for pattern matching and substitution. Additionally, the update introduces \to\_human\_time\_from\_seconds\ for human-readable time formatting, \decrypt\kv\ for secure key-value decryption, and a set of \version\\*\ filters (e.g., \version\_compare\, \version\_match\) for semantic versioning operations.
st2common/st2common/jinja · high confidence
New announcement and CloudSlang runners added
Added the \announcement\ runner, which dispatches events to a message stream, and the \cloudslang\ runner, which executes CloudSlang flows via the \cslang\ CLI. Both runners include configuration files and unit tests to support their respective functionalities.
_contrib/runners/announcement\_runner, contrib/runners/cloudslang\runner · high confidence
New command-line utilities for testing, re-firing, and managing reactor components
Added new command-line entry points for the StackStorm reactor subsystem: a garbage collector service, a rules engine runner, a sensor container manager, a rule tester for validating rules against trigger instances, and a trigger re-firing utility. These scripts provide dedicated interfaces for managing background tasks, testing rule logic, and debugging trigger events, each with their own configuration and logging setup.
st2reactor/st2reactor/cmd · high confidence
New concurrency and retry policy applicators
The policies module now includes new policy applicators for managing action execution: ConcurrencyApplicator and ConcurrencyByAttributeApplicator, which enforce limits on concurrent action runs by tracking scheduled and running instances, and ExecutionRetryPolicyApplicator, which automatically retries failed or timed-out actions based on configurable conditions and delays.
st2actions/st2actions/policies · high confidence
New configuration files for log rotation and environment-specific settings
Added logrotate configuration (conf/logrotate.conf) to manage log rotation for all StackStorm services (rules engine, auth, API, stream, etc.) using st2ctl to reopen log files. Introduced environment-specific configuration files (st2.dev.conf, st2.prod.conf, st2.package.conf, st2.tests.conf, st2.tests1.conf) that define service settings such as database hosts, logging paths, and authentication backends. Also added a sample CLI configuration (st2rc.sample.ini) for the StackStorm CLI, including token caching and timezone settings, and a demo encryption key file for the key-value store.
conf · high confidence
New content registration and loading infrastructure
A new content module has been introduced in st2common to handle the registration and loading of resources such as actions, sensors, rules, and packs. This includes a bootstrap script that orchestrates the registration of various resource types, a content loader that retrieves content from multiple directories and packs, and utility functions for managing pack paths and validating pack names. Users can now explicitly register content via the bootstrap script, with options to register specific resource types, set up virtual environments for packs, and control failure behavior.
st2common/st2common/content · high confidence
New core actions for UUID generation, pausing, and announcements
The core actions library has been expanded with several new capabilities. A new 'uuid' action allows users to generate UUIDs of type uuid1 or uuid4. A 'pause' action has been added to introduce delays in workflows, supporting both fixed and random pause durations. Additionally, an 'announcement' action is introduced to broadcast messages to all stream consumers. The 'sendmail' action has been updated to support sending empty email bodies and accepting file attachments. The 'http' action now accepts float values for the timeout parameter, and the 'windows' action has been renamed to 'windows\_cmd' for clarity.
contrib/core/actions · high confidence
New logging configuration files for st2actions components
The st2actions package now includes dedicated logging configuration files for each of its sub-components: console, file-based logging, syslog, notifier, and results tracker. These new .conf files in st2actions/conf define specific log levels, handlers (such as console, file, audit, and syslog), and formatters (including JSON and GELF formats) for each component, allowing users to customize how logs are captured and formatted for each service.
st2actions/conf · high confidence
New pack management actions for content lifecycle
A comprehensive set of new actions has been introduced in the \contrib/packs/actions\ directory to manage the full lifecycle of StackStorm packs. This includes \install\, \uninstall\, \load\, \unload\, \delete\, \download\, \update\_virtualenv\, and \setup\_virtualenv\, alongside utility actions like \get\, \search\, \show\, and \restart\_component\. These changes enable users to download, install, and register pack content, manage Python virtual environments for pack dependencies, and reload or unregister content components, providing a more integrated and automated approach to pack management within the local content repository.
contrib/packs/actions · high confidence
New pack management actions for installation, removal, and registration
The pack management functionality has been reorganized into a new \pack\_mgmt\ module containing dedicated actions for each pack lifecycle stage. Users can now interact with new endpoints: \packs.download\ to fetch pack source code, \packs.install\ to set up the environment, \packs.register\ to register pack components with the system, \packs.uninstall\ to remove pack files and virtual environments, and \packs.unload\ to unregister pack components from the database. Additionally, utility actions \packs.get\_installed\ and \packs.search\ allow users to inspect local and remote pack information, while \packs.setup\_virtualenv\ handles environment preparation and \packs.delete\ removes pack directories.
_contrib/packs/actions/pack\mgmt · high confidence
New scripts for requirements management and version population
Added new utility scripts to the build and packaging workflow. The \fixate-requirements.py\ script automates the generation of pinned \requirements.txt\ files by merging component-specific \in-requirements.txt\ files with a central \fixed-requirements.txt\ manifest, ensuring consistent dependency versions across the StackStorm stack. The \dist\_utils.py\ module provides helper functions for parsing requirements and applying a Vagrant-specific workaround for shared folders. Additionally, \populate-package-meta.sh\ and \populate-version.sh\ scripts were introduced to automatically populate package metadata and version information during the build process.
scripts · high confidence
New st2ctl and utility scripts for service management and validation
A new st2ctl script has been introduced to manage StackStorm services, supporting systemd, upstart, and SysV init systems. The update also adds several new command-line utilities in st2common/bin: st2-check-license for validating license keys, st2-self-check for running self-tests, st2-run-pack-tests for executing pack tests, and scripts for generating and validating API specs and pack configurations. Additionally, a new st2-apply-rbac-definitions script is added to apply RBAC definitions.
st2common/bin · high confidence
New system and file utility functions for debug tooling
The debug tooling now includes new utility modules for gathering system information and managing files. The system\_info module provides functions to retrieve CPU, memory, and package list details from the host system. The fs module adds helpers for listing files, copying files, and removing files or directories. The git\_utils module adds a function to retrieve the latest repository revision hash, handling cases where the repository path does not exist. These utilities support the debug tool's ability to collect and manage local state and metadata.
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. The \ResourceReference\ and \UserKeyReference\ classes are also added to manage resource and key-value lookups.
st2common/st2common/models/system · high confidence
New utility and migration scripts for development and maintenance
Added a suite of new tools in the \tools\ directory to assist with development, debugging, and database maintenance. This includes \config\_gen.py\ for generating configuration templates, \diff-db-disk.py\ for comparing database contents against disk files, and \st2-analyze-links.py\ for visualizing rule-based action links. Additionally, migration scripts (\migrate\_messaging\_setup.py\, \migrate\_rules\_to\_include\_pack.py\, \migrate\_triggers\_to\_include\_ref\_count.py\) are introduced to handle data schema updates, while \db\_cleanup.sh\ and \log\_watcher.py\ provide database reset and log analysis capabilities. The \launchdev.sh\ script is also added to streamline the local development environment setup.
tools · high confidence
Packaging and build infrastructure for st2actions
The st2actions component now includes a complete Python packaging setup, including a new setup.py that defines the package metadata, scripts, and dependencies. A dist\_utils.py module provides shared build utilities, such as a workaround for Vagrant shared folder issues. The build process is supported by a Makefile that handles wheel building, RPM and DEB packaging, and dependency injection. Additionally, a MANIFEST.in file ensures that necessary files like requirements.txt and license headers are included in source distributions.
st2actions · high confidence
Packaging infrastructure added for st2debug
The st2debug component now includes the necessary build and packaging files (setup.py, Makefile, MANIFEST.in, and in-requirements.txt) to support building and distributing the package as a wheel or RPM/DEB. This enables the component to be packaged and published into the shared wheelhouse, with a Vagrant-specific workaround applied during the build process.
st2debug, st2tests · high confidence
Standardize build, linting, and CI configuration files
The repository introduces standardized configuration files to improve code quality and build consistency. A new Makefile is added to manage component builds, tests, and linting targets. Linting is configured via .flake8 and .pylintrc files that point to shared linting rules. CI coverage and status are managed through .codecov.yml and .scrutinizer.yml. Additionally, .gitignore and .agignore are updated to exclude build artifacts, virtual environments, and editor-specific files from version control.
(repo-wide) · high confidence
Architecture
Database model architecture refactored into modular files
The database models for the system have been reorganized from a single file into separate modules (e.g., \action.py\, \auth.py\, \execution.py\). This change introduces a centralized \db\_setup\ function that automatically discovers and registers all model classes, ensuring database indexes are created upfront to prevent race conditions. Additionally, the models now support SSL connections to MongoDB and include specific index cleanup logic to handle MongoDB 3.4 compatibility issues.
st2common/st2common/models/db · high confidence
Initialize st2reactor package
Added an empty \_\init\\_.py file to the st2reactor package directory, marking it as a Python package.
st2reactor/st2reactor · high confidence
Mistral workflow utilities moved to st2common
Moved Mistral-related workflow utilities, including validation and Jinja rendering helpers, into the shared st2common package. This change improves code reuse and ensures consistent handling of Mistral workbook and task definitions across the platform.
st2common/st2common/util/workflow · high confidence
Refactor runner infrastructure into st2common
The runner support code has been moved from the st2actions package to st2common, establishing a new st2common/runners directory containing base classes (base.py, base\_action.py), the Python action wrapper (python\_action\_wrapper.py), and SSH/Windows runner implementations (paramiko\_ssh.py, parallel\_ssh.py, paramiko\_ssh\_runner.py, windows\_runner.py). This reorganization centralizes runner logic, improves import performance by avoiding expensive indirect imports, and provides a consistent interface for executing actions across different platforms.
st2common/st2common/runners · high confidence
Refactored content registration into a modular registrar system
The content registration logic in st2common has been refactored into a set of dedicated registrar classes (ActionsRegistrar, AliasesRegistrar, ConfigsRegistrar, PoliciesRegistrar, RulesRegistrar, RuleTypesRegistrar, RunnersRegistrar, and SensorsRegistrar) that all inherit from a new base ResourceRegistrar. This change introduces a consistent, pluggable architecture for registering StackStorm content, with each registrar handling a specific resource type. The base class provides shared functionality for pack discovery, caching, and error handling, while each registrar implements specific logic for its resource type. This modular approach improves code organization, maintainability, and allows for easier extension with new resource types.
st2common/st2common/bootstrap · high confidence
Behavioural changes
Add dedicated logging configurations for reactor components
New logging configuration files have been added for the sensor container, rules engine, and garbage collector services. Each component now has its own dedicated configuration files for console, file-based (RotatingFileHandler), and syslog logging, ensuring that logs for the sensor container, rules engine, and garbage collector are separated and properly formatted.
st2reactor/conf · high confidence
Added migration scripts for datastore scope and runner registration
New migration scripts have been added to upgrade existing data and system configuration. The v1.5 script migrates datastore items to include a 'secret' flag, while the v2.1 scripts update datastore items to use full scope identifiers (SYSTEM\_SCOPE, USER\_SCOPE) and register system runners via st2ctl.
st2common/bin/migrations · high confidence
Centralize and expand system constants in st2common
The st2common package now includes a comprehensive, organized constants module that consolidates previously scattered string literals and configuration values. This includes new live action statuses (such as 'abandoned' and 'requested'), updated action context prefixes, and dedicated constant files for authentication modes, error messages, exit codes, garbage collection intervals, key-value store scopes, logging configuration, pack metadata, rule types, runner timeouts, scheduler and timer log lines, secret masking attributes, sensor partition loaders, system versioning, trace identifiers, and resource type enumerations. These centralized constants standardize values across the codebase, ensuring consistent behavior for execution states, environment variables, and system resources.
st2common/st2common/constants · high confidence
Centralized service layer for core platform capabilities
The 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, and sensor watching. This refactoring consolidates previously scattered logic into a structured set of service classes and functions, such as DatastoreService for managing datastore items, CoordinationService for distributed worker coordination, and AccessService for handling token creation and deletion. Users benefit from a more maintainable and modular internal architecture, which supports features like user-scoped configuration items, encrypted secret values in the datastore, and improved execution tracking through the new service abstractions.
st2common/st2common/services · high confidence
Concurrency policy now supports configurable actions on threshold
The concurrency policy now allows users to specify which action to perform when the concurrency threshold is reached. Previously, the default behavior was to delay new executions; now, users can choose between 'delay' and 'cancel' via the new 'action' parameter. This change is reflected in the updated metadata definitions for concurrency and concurrency\_by\_attr policies, which now include the 'action' parameter with an enum of 'delay' or 'cancel'.
st2common/st2common/policies/meta · high confidence
Enhanced ChatOps message rendering with web URL and structured results
The default ChatOps template now includes the execution's web URL in the notification message, providing a direct link to the execution details. Additionally, the template has been updated to render execution results in a more structured and readable format, with specific handling for different runner types (such as HTTP requests, Python scripts, and shell commands) to better display output and error information.
contrib/chatops/actions/templates · high confidence
File watch sensor now accepts file paths via rule parameters
The Linux pack's file watch sensor has been updated to receive the file path to monitor through rule parameters rather than a deprecated config file approach. Users must now define a rule with a 'file\_path' parameter to specify which file to tail, as shown in the updated README example. The sensor still emits the same payload structure, but the method of providing the monitored file path has changed.
contrib/linux/sensors · high confidence
Introduce new runner container implementation
The runner container logic has been refactored into new files: \st2actions/st2actions/container/base.py\ and \st2actions/st2actions/container/service.py\. The \base.py\ file introduces a \RunnerContainer\ class that handles action dispatch, execution, and cancellation, while \service.py\ provides the \RunnerContainerService\ interface for runners to access container services. This change reorganizes the runner container code into a dedicated package structure.
st2actions/st2actions/container · high confidence
Introduces a new message transport layer with robust connection handling
The \st2common/transport\ package has been restructured to provide a modern, resilient messaging abstraction over RabbitMQ. This change introduces a \ConnectionRetryWrapper\ that automatically handles cluster failovers and transient connection errors, ensuring that message publishing and consumption remain stable during network hiccups. The new layer includes dedicated publishers and consumers for live actions, execution states, and trigger instances, along with a bootstrap utility to ensure exchanges are registered reliably at startup.
st2common/st2common/transport · high confidence
Major overhaul of the st2 CLI client architecture
The st2client commands have been refactored to use a new base class hierarchy (Command, Branch) defined in st2client/commands/\_\init\\_.py, replacing the previous implementation. This introduces a structured command tree with base classes for commands and branches, and updates all command implementations (e.g., action, pack, keyvalue, auth) to use these new base classes and decorators. The change also removes the dependency on st2common from st2client, hardcoding certain default values and logic previously shared.
st2client/st2client/commands · high confidence
Migrate CI infrastructure to CircleCI with enhanced service configuration
The project has replaced its previous CI provider with CircleCI, introducing new build scripts to manage test environments. This includes automated setup for MongoDB (with performance tuning and index-scan enforcement), PostgreSQL, and RabbitMQ, alongside a new SSH user configuration for integration tests. The change also adds environment variable handling for build versions and enables codecov integration.
.circle · high confidence
Migrate history view fixtures from JSON to YAML
The test fixtures for history views have been converted from JSON to YAML format. This change updates the internal structure of the \st2tests/st2tests/fixtures/history\_views\ module, which now loads YAML files to define filter configurations for execution views. This supports the broader capability of controlling the list of filters from the frontend.
_st2tests/st2tests/fixtures/history\views · medium confidence
Migrate v1 API controllers to the new RBAC permission model
The REST controllers in st2api/st2api/controllers/v1 (including actions, executions, and aliases) have been updated to enforce the new RBAC permission model. This change ensures that all create, read, update, and delete operations on these resources now require the appropriate RBAC permissions (e.g., \ActionView\, \ActionCreate\, \ActionModify\) to be granted to the requesting user. Additionally, the controllers now utilize the \ResourceController\ base class and the \rbac\_utils\ module for consistent permission checking and error handling.
st2api/st2api/controllers/v1 · high confidence
Mistral v2 query module refactored with jitter and state mapping updates
The Mistral v2 query module has been refactored to improve reliability and state handling. A random jitter delay has been added to HTTP calls when fetching task results, which helps prevent request bursts. The mapping of workflow states has been updated to correctly map the 'CANCELLED' state to the corresponding live action status. Additionally, the code now allows the querier plugin to decide whether to delete the state object on error, and redundant exception handling has been removed.
_contrib/runners/mistral\v2/query · medium confidence
New API validators for actions, triggers, and criteria
The API validation logic has been restructured into dedicated modules: action.py for validating action resources (including parameter immutability, default values, and position uniqueness), reactor.py for validating criteria objects and trigger parameters/payloads (with support for system and non-system triggers, including CronTimer validation), and misc.py for enforcing system pack restrictions. This change introduces stricter validation for action parameters, trigger parameters, and criteria, ensuring that invalid configurations are rejected with clear error messages.
st2common/st2common/validators/api · high confidence
New garbage collection modules for purging stale data
The st2common package now includes new modules for purging old data: executions, live actions, and trigger instances. The garbage collection logic has been moved from st2reactor to st2common, allowing st2common to operate without depending on st2reactor. The purge functions now log the number of deleted objects, providing visibility into the cleanup process.
_st2common/st2common/garbage\collection · high confidence
New logging configuration files for console, file, and syslog handlers
Added new configuration files (console.conf, logging.conf, syslog.conf) that define logging handlers for console output, file rotation, and syslog. The logging configuration introduces a GelfLogFormatter for audit logs, uses a custom ConfigurableSyslogHandler for syslog, and sets up RotatingFileHandler for application and audit logs.
st2api/conf · high confidence
Notifier and scheduler modules restructured into a dedicated package
The notifier and result tracker modules have been moved into a separate \st2actions/notifier\ package, with a standalone configuration file (\config.py\) and a new \scheduler.py\ for handling delayed execution recovery. This change also updates the notifier to scan the executions queue instead of the liveaction queue, utilizes \COMPLETED\_STATES\ and \FAILED\_STATES\ constants, and supports Jinja templating for message and data in notifications.
st2actions/st2actions/notifier · medium confidence
Python runner module reorganization
The Python runner implementation has been reorganized into a new module structure. The \pythonrunner.py\ file now imports and re-exports the \Action\ class from \st2common.runners.base\action\, while the \\\init\\_.py\ file is created to support this new module layout.
st2actions/st2actions/runners · high confidence
Querier base class moved to st2common
The base class for query providers has been moved to the st2common package, providing a standardized interface for querying external services. The implementation now supports configurable query intervals and thread pool sizes, with a new configuration group 'resultstracker' replacing the deprecated 'results\_tracker' group. Additionally, the querier will now automatically delete state objects on error, improving error handling for failed queries.
st2common/st2common/query · high confidence
Re-organized test pack fixtures structure
The test fixtures for packs have been reorganized. A new \_\init\\_.py file was added to the st2tests/fixtures/packs directory, and a symbolic link named 'core' was created pointing to the contrib/core directory, indicating a structural change to how test packs are organized and accessed.
st2tests/st2tests/fixtures/packs · medium confidence
Refactor action alias and parameter utilities into st2common/models/utils
Moved and reorganized utility functions for action aliases, parameter casting, and sensor types into the st2common/models/utils package. This includes the new action\_alias\_utils.py for parsing and extracting parameters from action aliases, action\_param\_utils.py for validating and casting action parameters, profiling.py for MongoDB query logging, and sensor\_type\_utils.py for sensor type creation. These changes improve code reuse, fix bugs in alias parsing and parameter validation, and provide better error handling for invalid inputs.
st2common/st2common/models/utils · medium confidence
Refactor action execution asynchronous callback handling
The asynchronous callback mechanism for action executions has been refactored to use a new base class, AsyncActionExecutionCallbackHandler, which enforces a standardized interface for handling callback events. The Mistral v2 runner now utilizes this updated callback handler to map internal status codes to Mistral states and update execution results, ensuring consistent and reliable asynchronous status reporting.
_contrib/runners/mistral\v2/callback, st2common/st2common/callback · medium confidence
Refactor action execution into dedicated scheduler and worker components
The st2actions package is restructured to separate concerns: a new scheduler component now handles the initial dispatch of live actions and applies pre-run policies, while a worker component manages the actual execution and cancellation of actions. Configuration options for the action runner, dispatcher pools, and SSH runners are explicitly registered in the new config module, and the worker tracks running executions to handle cleanup on shutdown.
st2actions/st2actions · high confidence
Refactor action parameter validation and support default values
The schema validation logic for action parameters has been refactored to support assigning default values to nested object properties and to allow 'required: True' in combination with a default value without causing json schema validation to fail. A custom validator is now used for action parameters, which prevents the 'type' attribute from being an array, and ensures that default values are assigned before validation occurs, fixing issues where defaults would override explicitly provided values.
st2common/st2common/util/schema · medium confidence
Refactor authentication backend loading to use stevedore and add capability constants
The st2auth backends module now uses the stevedore library for dynamic backend loading and discovery, replacing the previous home-grown solution. This change introduces a new base class (BaseAuthenticationBackend) that defines standard methods like authenticate, get\_user, and get\_user\_groups, alongside a new constants file defining backend capabilities such as CAN\_AUTHENTICATE\_USER, HAS\_USER\_INFORMATION, and HAS\_GROUP\_INFORMATION. Users will see improved error handling and more descriptive exceptions when backend instantiation fails, and the system will now support dynamically importing backend modules without requiring all dependencies to be installed globally.
st2auth/st2auth/backends · medium confidence
Refactor service entry points and add signal handling
The service entry points for the action runner, notifier, and results tracker have been refactored to use a common setup and teardown module, reducing code duplication. Additionally, a SIGTERM signal handler has been added to the action runner to ensure consistent process shutdown, and the notifier now supports disabling the action rescheduler via configuration.
st2actions/st2actions/cmd · medium confidence
Refactor st2api to use WSGI middleware and OpenAPI router
The st2api service has been refactored to replace the Pecan framework with a WSGI-based architecture using an OpenAPI router. This introduces new middleware components for error handling, CORS, logging, and request IDs, while moving configuration options like 'allow\_origin' and 'mask\_secrets' to common settings. The change also adds validation to ensure RBAC is correctly configured when authentication is enabled, and updates the application setup to support both Gunicorn and standalone HTTP server modes.
st2api/st2api · medium confidence
Refactor st2common.util into modular utility files
The st2common.util package has been reorganized into distinct modules for better maintainability and reuse. New files include action\_db.py for action and liveaction database operations, actionalias\_helpstring.py and actionalias\_matching.py for alias processing, api.py for API URL construction, argument\_parser.py for CLI argument generation, auth.py for token and API key validation, casts.py for type casting, compat.py for string handling, config\_loader.py for pack configuration, config\_parser.py for YAML parsing, crypto.py for encryption, date.py for datetime utilities, debugging.py for debug mode, enum.py for enumerations, file\_system.py for file listing, and greenpooldispatch.py for green thread dispatching. This refactoring consolidates common functionality into reusable utility functions.
st2common/st2common/util · high confidence
Refactor stream controller to use OpenAPI router
The stream endpoint handler has been moved to the st2stream package and restructured into a new \StreamController\ class within \st2stream/controllers/v1/stream.py\. This change implements an OpenAPI-based routing structure, replacing the previous controller implementation with a dedicated stream controller that handles server-sent events via the \get\_all\ method.
st2stream/st2stream/controllers · medium confidence
Refactored API service entry point and setup logic
The API service entry point (st2api/st2api/cmd/api.py) has been restructured to centralize initialization and teardown logic. The new implementation explicitly registers configuration options, performs pre-runtime validation (such as RBAC configuration checks), and utilizes a shared service setup module for common tasks like database and message queue initialization. This change improves consistency across service entry points and ensures proper shutdown handling for the WSGI server.
st2api/st2api/cmd · high confidence
Refactored and improved API middleware components
The st2common middleware module has been restructured into separate, dedicated components for CORS headers, error handling, request ID tracking, and logging. The error handling middleware now converts internal exceptions into structured HTTP responses with appropriate status codes and JSON fault strings, while also ensuring that full API responses are logged at the DEBUG level rather than INFO to reduce log noise. The logging middleware has been updated to include the response body in debug logs, and the request ID middleware ensures every request has a unique ID for better traceability. These changes improve error reporting, log clarity, and request tracking across the API.
st2common/st2common/middleware · high confidence
Refactored logging infrastructure with new formatters and handlers
The logging module has been reorganized into a new \st2common.logging\ package, introducing custom log formatters (\ConsoleLogFormatter\, \GelfLogFormatter\) and handlers (\FormatNamedFileHandler\, \ConfigurableSyslogHandler\). This change enables improved debug logging, recursive serialization of objects in log messages, and the ability to mask sensitive data in logs via the \log.mask\_secrets\ configuration option. Additionally, log file names now use Unix timestamps, and log files are re-opened on the SIGUSR1 signal.
st2common/st2common/logging · medium confidence
Refactored st2common build and packaging infrastructure
The st2common package now uses a new build system that centralizes dependency management via an in-requirements.txt file and a shared dist\_utils.py helper. This refactoring introduces a Vagrant-specific workaround to prevent build failures in shared directories, updates the setup.py to explicitly specify the package name, and includes new scripts such as st2-apply-rbac-definitions and st2-self-check in the package. The Makefile has been updated to support building RPM and DEB packages, with specific configurations for RHEL6 and Debian-based systems.
st2common · medium 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 schema to support SSL/TLS, debug mode, and authentication backend selection. Users will see improved error handling, consistent JSON responses, and better logging context in the authentication service.
st2auth/st2auth · high confidence
Reorganize persistence layer into individual modules
The persistence layer in st2common has been refactored to improve code organization and reduce import dependencies. Each resource type (e.g., Action, User, Rule, Trigger) now has its own dedicated Python module within the persistence package, replacing the previous monolithic structure. This change also introduces a more consistent base class for database access, enabling better separation of concerns and easier maintenance of database operations across the application.
st2common/st2common/persistence · high 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 have been introduced: \BaseActionTestCase\ for Python runner actions, \BaseSensorTestCase\ for sensors, and \BaseActionAliasTestCase\ for action aliases, each providing specialized assertion methods and instance retrieval. A \FixturesLoader\ utility class was added to simplify loading test fixtures into the database, and a \BasePackResourceTestCase\ was created to handle common pack resource loading. Additionally, a \TestApp\ wrapper for \webtest\ was introduced to validate API responses for security (secret leakage) and CORS compliance. The \st2tests\ package structure was updated to export these new classes and utilities.
st2tests/st2tests · high confidence
Result tracker module refactored into a standalone package
The result tracker functionality has been moved from the st2actions root into a dedicated st2actions/resultstracker package, including a new config.py for independent configuration and a refactored resultstracker.py that now uses get\_messaging\_urls for connections. This structural change is accompanied by a behavioral change: the get\_logging\_config\_path function no longer requires a 'service' argument, and the tracker now dynamically loads query modules via register\_query\_module, allowing it to handle multiple query backends.
st2actions/st2actions/resultstracker · high confidence
Simplified index page with version and documentation link
The API index page now displays a static welcome message showing the StackStorm version and a link to the documentation, rather than redirecting to the web UI or showing a broken page. This change ensures users see a functional landing page with version information and documentation access by default.
st2api/st2api/templates · high confidence
Timer implementation refactored to use APScheduler and new schema validation
The timer component has been refactored to use APScheduler 3.0 for job scheduling, replacing the previous internal mongoengine-based functionality. The new St2Timer class now utilizes TriggerWatcher and TriggerDispatcher to manage timer triggers, with added schema validation via util\_schema.validate to ensure consistent rule application. This change also introduces exclusive queue suffixes for the trigger watcher and updates affected tests to align with the new implementation.
st2reactor/st2reactor/timer · medium confidence
Updated dummy\_pack\_1 fixture with valid metadata and configuration schema
The dummy\_pack\_1 test fixture was reorganized and updated to ensure pack validation passes. The pack metadata (pack.yaml) now includes a valid version number (0.1.0) and contributor details, while a new config.schema.yaml defines required string fields (api\_key, api\_secret, region) with appropriate types and defaults. This change ensures the test pack passes validation and supports new test cases for pack fields.
_st2tests/st2tests/fixtures/packs/dummy\_pack\1 · medium confidence
Updated test pack fixtures to use valid versions and correct configurations
The dummy\_pack\_2 and dummy\_pack\_3 test fixtures have been reorganized and updated. dummy\_pack\_2 now includes a properly configured action (my\_action) with a valid runner type (local-shell-script) and a policy (policy\_3) for testing. dummy\_pack\_3's action definition has been corrected to use the valid runner type 'local-shell-cmd' instead of the previously invalid 'local-shell-script' or other incorrect types, ensuring that validation does not fail during tests.
_st2tests/st2tests/fixtures/packs/dummy\_pack\2 · medium confidence
Fixes
Consolidate test fixtures into a single directory
Test fixtures have been moved into the st2tests/fixtures directory, centralizing the location of test data and helpers for the st2tests package.
st2tests/st2tests/fixtures · high confidence
Empty bootstrap init files added for actions and reactor
Empty \_\init\\_.py files were added to the st2actions and st2reactor bootstrap packages, establishing the directory structure for content registration.
st2actions/st2actions/bootstrap, st2reactor/st2reactor/bootstrap · medium confidence
Move ubuntu-pkg-info example action to examples directory
The ubuntu-pkg\_info action has been relocated from the core repository to the contrib/examples/actions directory. This move makes the example action available as a reference implementation for users to adapt, rather than being bundled as a core feature.
_contrib/examples/actions/ubuntu\_pkg\info · medium confidence
Test coverage
Add integration tests for Gunicorn WSGI entry points; Add test configuration files for logging and environment setup; Add test fixtures and test cases for sensor configuration and instantiation; Add test fixtures for Mistral and StackStorm configurations; Add test fixtures for execution and CLI configuration; Add test fixtures for pack validation and error handling; Add test packs for validating action exit codes and load average checks; Added Mistral integration tests; Added SSH test resources for paramiko; Added Twilio integration pack fixture for testing; Added automated SSH runner integration tests; Added empty \_\init\\.py files to test directories; Added empty \\init\\.py for st2actions/tests; Added empty test module initialization; Added execution test fixtures for actions, runners, and triggers; Added extensive unit tests for st2common; Added htpasswd test fixture; Added integration test fixtures for st2api and st2sensorcontainer logs; 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 st2-register-content script; Added integration tests for the debug info submission tool; Added integration tests for the export worker and dumper; Added local runner test fixture for text generation; Added missing \\init\\_.py for the tests package; Added mock runner fixtures for testing; Added sample sensor fixture for testing sensor enable/disable operations; Added test fixtures and mock runners for integration testing; Added test fixtures for action parameter validation and serialization; Added test infrastructure for st2auth; Added test infrastructure for the CLI client; Added test logging configuration for audit support; Added test package structure for st2reactor; Added test resources for Python action execution scenarios; Added test resources for loadable plugin functionality; Added test utilities for policy evaluation; Added tests for chatops execution result formatting; Added tests for pack management actions; Added tests for the GenerateUUID action; Added tests for the isprime action; Added unit tests for Mistral workflow and workbook validation; Added unit tests for action policies; Added unit tests for core services; Added unit tests for st2auth components; Added unit tests for system info utilities; Added unit tests for the Dumper and JSON converter components; Added unit tests for the HTTP runner client; Added unit tests for the Mistral v2 runner; Added unit tests for the Python runner; Added unit tests for the st2client CLI; Added unit tests for the stream controller; Added unit tests for the v1 token controller; Added unit tests for validation utilities; Expanded unit test coverage for action execution and SSH runners; Expanded unit test coverage for v1 API controllers; New test infrastructure for API controllers; Unit tests for controllers moved to separate directories; Unit tests reorganized into a dedicated directory.
Dependencies
Introduce per-pack and per-component requirements.txt files
The project now generates and maintains separate requirements.txt files for each pack and component (e.g., st2client, examples, linux, hello\_st2, and test fixtures). This change isolates dependencies, ensuring that each pack or tool installs only the libraries it actually needs, which simplifies dependency management and reduces the risk of version conflicts across different parts of the system.
(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 (214)
- 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 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)
- Duplicated block (12 lines × 2) (st2common/st2common/bootstrap/sensorsregistrar.py)
- …and 194 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
sh1nu11b1/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.