Run charm integration tests to reproduce test failures and issues. Uses scripts/run-tests.sh with test observer parameters to recreate exact test scenarios locally.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Run charm integration tests to reproduce test failures and issues. Uses scripts/run-tests.sh with test observer parameters to recreate exact test scenarios locally.
Skill: run-charm-tests
Goal
Run charm integration tests via scripts/run-tests.sh to reproduce test failures and issues. Given test observer execution parameters, recreate the exact test scenario and execute it locally.
Overview
This skill bridges the gap between:
Test Observer Execution Data - Parameters from a failed test run (charm names, endpoints, cloud types, etc.)
Local Test Execution - Running those tests locally to reproduce and debug issues
State Machine - Understanding the test lifecycle and progression
Prerequisites
Before using this skill, ensure the environment is set up:
/setup-charm-tests
This installs:
✅ LXD (machine cloud substrate)
✅ Canonical Kubernetes (K8s cloud substrate)
✅ juju-crashdump (machine controller logs)
✅ juju-k8s-crashdump (K8s controller logs) — Required for issue #693
✅ kubectl (K8s debugging)
✅ Bootstrapped controllers ready for testing
Tip: The setup-charm-tests skill is idempotent—safe to run multiple times.
Quick Start
Minimal Example - Single Cloud (LXD)
# Test a single charm on LXD (machine cloud)
./scripts/run-tests.sh \
--target-cloud "localhost" \
--target-charm "postgresql" \
--target-endpoint "database" \
--neighbor-charm \
--neighbor-endpoint \
--current-state \
--charm-overrides \
--log-dir
"pgbouncer"
"database"
"no_bundle"
"./static/charm-overrides/"
"./test-logs"
With Cross-Model Relation (CMR) - Mixed Clouds
# Test with target on LXD (machine) and neighbor on K8s
./scripts/run-tests.sh \
--target-cloud "localhost" \
--target-charm "glauth-utils" \
--target-endpoint "glauth-auxiliary" \
--target-series "22.04" \
\
--neighbor-cloud "local-k8s" \
--neighbor-charm "glauth-k8s" \
--neighbor-endpoint "glauth-auxiliary" \
\
--current-state "no_bundle" \
--charm-overrides "./static/charm-overrides/" \
--log-dir "./test-logs" \
--log-cli-level "INFO"
With Full Test Observer Parameters (CMR Mixed Clouds)
Using Custom Controller Names (For Concurrent Execution)
When multiple agents or users run tests simultaneously, use unique controller name prefixes to avoid conflicts. The --prefix parameter controls all generated resource names (controllers, models, bundles).
Generating Unique Prefixes
Option 1: Timestamp-based (recommended for simple cases)
The test suite handles setup, execution, and teardown automatically.
Option B: Manual Cloud Setup (for interactive development)
Use the /setup-lxd or /setup-k8s skills to provision a cloud substrate. The test suite will bootstrap controllers when you run tests with --current-state.
Cloud Type Detection Logic
If cloud/platform contains:
- "kubernetes" or "k8s" → Kubernetes (local-k8s cloud)
- "machine" → LXD (localhost cloud)
- "openstack" or "nova" → OpenStack (requires credentials)
- "production" → Use secrets/environment config
3. State Machine - Test Lifecycle
The test execution follows a strict state machine that pytest manages via decorators and fixtures:
Core component for tracking and managing Juju resources:
# What it tracks:
registry[JujuControllerHandle]
├── bootstrap config
├── cloud type (K8s vs machine)
├── models
└── log collectors
registry[JujuModelHandle]
├── parent controller
├── applications
└── units
Log Collection Integration:
# In conftest.py:
JujuCrashdumpCollector(
logger=logger,
output_dir=Path("./test-logs"),
kubeconfig_path=kubeconfig_path, # For K8s controllers
)
# On teardown, collector checks each controller:# 1. Detects if controller is K8s or machine# 2. Calls appropriate crashdump tool# 3. Archives logs to .tar.gz
After the test fails (or completes), inspect manually:
# List controllers that were created
juju models -c target
# SSH into a unit
juju ssh -m target/mymodel 0 journalctl -n 100
# Check what charms are deployed
juju status -m target/mymodel
Implementation Details
Test Execution Command
The skill translates test observer parameters to run-tests.sh invocation:
Understanding Test Results: State Machine & Cascade Skips
The test framework uses an internal state machine to manage test dependencies. Understanding this prevents confusion about skipped tests.
How the State Machine Works
Tests are marked with state requirements like:
test_build_bundle: no_bundle → bundle_built
test_deploy: bundle_built → deployed
test_upgrade_charm: deployed → charm_upgraded
When you specify --current-state "no_bundle", the scheduler:
Starts from that state
Runs tests to reach subsequent states
Skips tests that aren't on the path to the final state
Cascade Skips After Test Failure
Important: When a state-transition test fails, all subsequent state-marked tests are automatically skipped because the environment state is now unknown.
✅ test_logs_privacy_check and log collection to complete
Key Point: Log collection runs in the teardown phase (finally block), so excluding environmental failures ensures both controllers reach log collection even if deployment phases fail.
Troubleshooting
Problem: "Controller already exists"
The charm-testing workflow reuses cloud names. If you have existing controllers:
K8s cloud setup might be incomplete. Before running tests:
# Check if K8s cloud is registered
juju clouds | grep local-k8s
# If not found, install and configure K8s# (See setup-k8s skill documentation)$PROJECT_ROOT/development-sandbox/bin/setup-k8s.sh
# Bootstrap a K8s controller
juju bootstrap local-k8s k8s-ctrl