Merge "Add initial framework and SSH documentation"
This commit is contained in:
@@ -2,10 +2,48 @@
|
||||
**framework/** Documentation
|
||||
============================
|
||||
|
||||
This section covers the **testing framework** used in StarlingX.
|
||||
The **framework/** directory contains core infrastructure for the StarlingX Test
|
||||
Automation Framework, including logging, SSH, threading, database operations,
|
||||
REST clients, runner logic, and other essential utilities that power keyword
|
||||
execution and test orchestration.
|
||||
|
||||
Design Principles
|
||||
=================
|
||||
|
||||
The framework layer is built for reliability, extensibility, and separation of concerns:
|
||||
|
||||
- **Reusable building blocks**: Shared services such as SSH, threading, and logging are centralized here.
|
||||
- **Test-agnostic logic**: This layer should not depend on specific testcases or keyword domains.
|
||||
- **Isolation from test logic**: Business logic and automation commands live in `keywords/` or `testcases/`,
|
||||
while framework components focus on supporting infrastructure.
|
||||
- **Consistent logging and error handling**: All modules use the same logger and exception patterns.
|
||||
|
||||
--------
|
||||
Contents
|
||||
--------
|
||||
|
||||
*(Additional framework documentation will be added here.)*
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
ssh/index
|
||||
|
||||
Directory Structure
|
||||
===================
|
||||
|
||||
An overview of the key subdirectories in **framework/**:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
framework/
|
||||
├── database/ # Handles test result storage and querying
|
||||
├── exceptions/ # Custom framework exception classes
|
||||
├── logging/ # Logging setup, formatting, and filtering
|
||||
├── pytest_plugins/ # Plugins for customizing test discovery and result capture
|
||||
├── resources/ # Static resources and backup files
|
||||
├── rest/ # REST client interfaces and response helpers
|
||||
├── runner/ # Scripts and objects for test execution
|
||||
├── scanning/ # Handles scan and upload of test artifacts
|
||||
├── ssh/ # SSH connections, prompts, and secure transfers
|
||||
├── threading/ # Multi-threading infrastructure
|
||||
├── validation/ # Generic input validation utilities
|
||||
└── web/ # Web automation helpers (actions, conditions, locators)
|
||||
|
50
doc/source/framework/ssh/index.rst
Normal file
50
doc/source/framework/ssh/index.rst
Normal file
@@ -0,0 +1,50 @@
|
||||
================================
|
||||
**framework/ssh/** Documentation
|
||||
================================
|
||||
|
||||
The **framework/ssh/** directory provides SSH-related infrastructure for the
|
||||
StarlingX Test Framework. It includes utilities for establishing remote
|
||||
connections, handling interactive prompts, and performing secure file transfers.
|
||||
|
||||
This layer is designed to be reusable across the entire framework, and abstracts
|
||||
SSH complexity away from keywords and test logic.
|
||||
|
||||
--------
|
||||
Contents
|
||||
--------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:caption: SSH Modules
|
||||
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The SSH layer encapsulates all logic related to:
|
||||
|
||||
- **Establishing connections** (with or without jump hosts).
|
||||
- **Executing remote commands** (including interactive or sudo-based workflows).
|
||||
- **Handling prompts** using reusable response objects.
|
||||
- **Secure file transfers** using built-in Paramiko support.
|
||||
- **Cleaning up output** (e.g., removing ANSI sequences).
|
||||
|
||||
These modules are used by keyword implementations to run system-level commands
|
||||
on remote hosts in a consistent and fault-tolerant manner.
|
||||
|
||||
Connection Behavior
|
||||
===================
|
||||
|
||||
The SSH connection adapts based on the test lab's setup and the type of command being executed:
|
||||
|
||||
1. Check whether a jump host is required.
|
||||
2. If needed, connect to the jump host using Paramiko.
|
||||
3. Open a channel to the final destination (target host).
|
||||
4. Establish the SSH session to the target host.
|
||||
5. Use one of the following modes:
|
||||
|
||||
- ``exec_command()`` for simple non-interactive commands.
|
||||
- ``invoke_shell()`` when prompt interaction or ``sudo`` is needed.
|
||||
|
||||
6. Execute the command and capture output.
|
||||
7. Strip any ANSI escape sequences for cleaner parsing/logs.
|
Reference in New Issue
Block a user