mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-04-29 03:50:18 +00:00
0fcfad3dc5
Implements a comprehensive script improvement infrastructure to reduce code duplication, improve maintainability, and enable easier testing of installer scripts. ## New Infrastructure ### Shared Library System (scripts/lib/) - common.sh: Core utilities (logging, sudo, dry-run, cleanup management) - systemd.sh: Service management helpers with container-safe systemctl - http.sh: HTTP/download helpers with curl/wget fallback and retry logic - README.md: Complete API documentation for all library functions ### Bundler System - scripts/bundle.sh: Concatenates library modules into single-file installers - scripts/bundle.manifest: Defines bundling configuration for distributables - Enables both modular development and curl|bash distribution ### Test Infrastructure - scripts/tests/run.sh: Test harness for running all smoke tests - scripts/tests/test-common-lib.sh: Common library validation (5 tests) - scripts/tests/test-docker-agent-v2.sh: Installer smoke tests (4 tests) - scripts/tests/integration/: Container-based integration tests (5 scenarios) - All tests passing ✓ ## Refactored Installer ### install-docker-agent-v2.sh - Reduced from 1098 to 563 lines (48% code reduction) - Uses shared libraries for all common operations - NEW: --dry-run flag support - Maintains 100% backward compatibility with original - Fully tested with smoke and integration tests ### Key Improvements - Sudo escalation: 100+ lines → 1 function call - Download logic: 51 lines → 1 function call - Service creation: 33 lines → 2 function calls - Logging: Standardized across all operations - Error handling: Improved with common library ## Documentation ### Rollout Strategy (docs/installer-v2-rollout.md) - 3-phase rollout plan (Alpha → Beta → GA) - Feature flag mechanism for gradual deployment - Testing checklist and success metrics - Rollback procedures and communication plan ### Developer Guides - docs/script-library-guide.md: Complete library usage guide - docs/CONTRIBUTING-SCRIPTS.md: Contribution workflow - docs/installer-v2-quickref.md: Quick reference for operators ## Metrics - Code reduction: 48% (1098 → 563 lines) - Reusable functions: 0 → 30+ - Test coverage: 0 → 8 test scenarios - Documentation: 0 → 5 comprehensive guides ## Testing All tests passing: - Smoke tests: 2/2 passed (8 test cases) - Integration tests: 5/5 scenarios passed - Bundled output: Syntax validated, dry-run tested ## Next Steps This lays the foundation for migrating other installers (install.sh, install-sensor-proxy.sh) to use the same pattern, reducing overall maintenance burden and improving code quality across the project.
45 lines
1.7 KiB
Markdown
45 lines
1.7 KiB
Markdown
# Integration Tests
|
|
|
|
The scripts in this directory exercise the Pulse installer scripts inside isolated
|
|
environments (typically Linux containers). They are intended to catch regressions
|
|
that unit-style smoke tests cannot detect (e.g., filesystem layout, systemd unit
|
|
generation, binary placement).
|
|
|
|
## Prerequisites
|
|
|
|
- Docker or another container runtime supported by the test script. When Docker
|
|
is unavailable the test will skip gracefully.
|
|
- Internet access is **not** required; HTTP interactions are stubbed.
|
|
|
|
## Running the Docker Agent Installer Test
|
|
|
|
```bash
|
|
scripts/tests/integration/test-docker-agent-install.sh
|
|
```
|
|
|
|
The script will:
|
|
|
|
1. Launch an Ubuntu 22.04 container (when Docker is available).
|
|
2. Inject lightweight stubs for `systemctl`, `docker`, `curl`, and `wget`.
|
|
3. Execute the refactored installer through several scenarios (dry run,
|
|
full install, missing Docker handling, multi-target configuration, uninstall).
|
|
|
|
The container is discarded automatically, and no files are written to the host
|
|
outside of the repository.
|
|
|
|
## Adding New Integration Tests
|
|
|
|
1. Place new test scripts in this directory. They should follow the pattern of
|
|
detecting required tooling, skipping when prerequisites are missing, and
|
|
producing clear PASS/FAIL output.
|
|
2. Prefer running inside an ephemeral container to avoid modifying the host
|
|
system.
|
|
3. Use repository-relative paths (`/workspace` inside the container) and avoid
|
|
relying on network resources.
|
|
4. Clean up all temporary files even when the test fails (use traps).
|
|
|
|
## Reporting
|
|
|
|
Each integration script is self-contained and prints a concise summary at the
|
|
end. CI jobs or developers can invoke them individually without modifying
|
|
the top-level smoke test harness.
|