Compare commits

..

10 Commits

Author SHA1 Message Date
Countess von Containerheim 4c71fab41b Merge pull request 'chore: Configure Renovate' (#64) from renovate/configure into main
CI / lint (push) Failing after 3s
chore: Configure Renovate
2026-05-20 03:03:45 +00:00
Chris Farhood 7183381140 Fix typo in GitHub authentication section 2026-05-14 07:38:58 -04:00
Chris Farhood 611334167b Update GitHub authentication instructions
Removed note about token expiration for GitHub authentication.
2026-05-14 07:38:45 -04:00
Chris Farhood a3bab704df Update SKILL.md 2026-05-14 07:38:30 -04:00
privilegedescalation-engineer[bot] c48eccd70c Update SDLC skill: add UAT_PLAYBOOK.md maintenance requirement (PRI-1487) 2026-05-14 04:16:25 +00:00
privilegedescalation-engineer[bot] ea1f585722 Rework UAT skill: remove per-plugin tables, reference UAT_PLAYBOOK.md 2026-05-14 04:15:34 +00:00
privilegedescalation-engineer[bot] bedef6ab6a remove test file 2026-05-14 04:14:49 +00:00
privilegedescalation-engineer[bot] 1fe4f900b0 test 2026-05-14 04:14:28 +00:00
privilegedescalation-qa[bot] 44e528c373 Add dedicated UAT skill with plugin testing procedures
Add dedicated UAT skill with plugin testing procedures
2026-05-14 03:15:29 +00:00
privilegedescalation-engineer[bot] f9b3ea1882 Add renovate.json 2026-05-13 17:34:33 +00:00
3 changed files with 51 additions and 42 deletions
+6
View File
@@ -0,0 +1,6 @@
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": [
"local>privilegedescalation/.github:renovate-config"
]
}
+3 -5
View File
@@ -10,9 +10,7 @@ description: >
## GitHub Authentication
**Invoke the `github-app-token` skill** before any GitHub operation. It generates a short-lived installation token and sets `GH_TOKEN`. **Never** run `gh auth login` directly — it hangs headless agents.
Token expires after ~1 hour. Re-invoke the skill to regenerate if needed.
Access to GitHub is done via token in your env **Never** run `gh auth login` directly — it hangs headless agents.
## GitHub Issues — Board Approval Required
@@ -69,8 +67,6 @@ Each promotion is a PR reviewed and merged by its gate owner:
2. **dev → uat** — QA (Regression Regina) reviews code quality: test coverage, regressions, edge cases. QA merges to `uat` after approval.
3. **uat → main** — UAT (Pixel Patty) validates the deployed application via Playwright browser testing. UAT merges to `main` after validation passes. For detailed UAT testing procedures, see the `uat` company skill.
**Playbook maintenance:** When plugin testing procedures change (new features, changed UI, different access paths), the engineer must update the plugin's `UAT_PLAYBOOK.md` in the same PR. This is a required deliverable alongside the code change — not optional cleanup.
**Each gate owner has merge authority.** No separate merge step by another role. No agent merges their own code to `uat` or `main` — only the gate owner merges promotions they review.
## Pipeline
@@ -88,6 +84,8 @@ Engineer → PR to dev → self-merge → deploys to dev
Applies to changes in `headlamp-*-plugin/` repos (plugin code, features, bug fixes).
**UAT_PLAYBOOK.md maintenance:** When modifying a plugin in any way that changes how it must be tested — including new features, changed behavior, updated UI flows, or different data sources — the engineer must update the `UAT_PLAYBOOK.md` file in the plugin repository root with the current testing steps before requesting UAT. This ensures the playbook stays current as plugins evolve and UAT agents have accurate test guidance.
### Pipeline B: Infrastructure Changes (No UI Impact)
```
+42 -37
View File
@@ -1,40 +1,20 @@
---
name: uat
description: >
Functional UAT procedures for Privileged Escalation Headlamp plugins. Delegates per-plugin testing procedures to UAT_PLAYBOOK.md in each plugin repository.
Functional UAT procedures for Privileged Escalation Headlamp plugins. General
behavior, acceptance criteria, artifact requirements, and reference to
plugin-specific test steps in UAT_PLAYBOOK.md.
---
# UAT Procedures
## Purpose
This skill defines **functional User Acceptance Testing** for all Privileged Escalation Headlamp plugins. UAT validates that plugins work correctly in the deployed environment — by loading plugins in a running Headlamp instance and exercising their features.
This skill defines **functional User Acceptance Testing** for all Privileged Escalation Headlamp plugins. UAT validates that plugins work correctly in the deployed environment — by exercising plugin features in a running Headlamp instance, not by reviewing code or CI results.
## Pipeline Stage
## UAT Environment
UAT is the final promotion gate before production: `uat → main`. Pixel Patty (UAT agent) validates the deployed application via Playwright browser testing before merging.
## Per-Plugin Testing Procedures
Detailed, up-to-date testing procedures for each plugin are maintained in the plugin's own repository at `UAT_PLAYBOOK.md`. This is the authoritative source — do not copy procedure details into this skill.
| Plugin | Repository |
|--------|------------|
| headlamp-polaris-plugin | `polaris` |
| headlamp-sealed-secrets-plugin | `sealed-secrets` |
| headlamp-intel-gpu-plugin | `intel-gpu` |
| headlamp-kube-vip-plugin | `kube-vip` |
| headlamp-tns-csi-plugin | `tns-csi` |
| headlamp-rook-plugin | `rook` |
| headlamp-argocd-plugin | `argocd` |
Each plugin's `UAT_PLAYBOOK.md` contains:
- Access path (sidebar entry or app bar location)
- Step-by-step test actions
- Expected results for each step
- Pass/fail criteria
- Artifact requirements (screenshots, console errors, environment info)
The UAT Headlamp instance runs in the `headlamp-uat` Kubernetes namespace. Navigate to the Headlamp UAT URL using your Playwright browser. The plugin under test must be deployed to UAT before testing begins.
## General Process
@@ -42,23 +22,48 @@ For every `uat→main` promotion:
1. Open the Headlamp UAT instance in the browser
2. Confirm the plugin appears in the sidebar or app bar
3. Retrieve the plugin's `UAT_PLAYBOOK.md` from its repository
4. Execute the test steps in the playbook
5. Capture screenshots of the **running plugin** at each verification step
6. Check the browser console for errors
7. Post a structured test report (see Artifacts section)
3. Read the plugin's `UAT_PLAYBOOK.md` for the specific test steps to run
4. Execute the test steps from the playbook, capturing screenshots at each verification
5. Check the browser console for errors throughout
6. Post a structured test report (see Artifacts section)
## UAT Artifacts
## Acceptance Criteria
A plugin passes UAT when:
- **Plugin loads** — sidebar entry or app bar action is visible and accessible
- **Features work** — all core features in the playbook execute without errors
- **No console errors** — browser console shows no errors during normal operation
- **Data matches cluster state** — plugin data is consistent with `kubectl` queries against the cluster
A plugin fails UAT when:
- Plugin does not load or renders only an error state
- Any core feature is inaccessible or produces errors
- Console errors are present and not explainable as unrelated noise
- Displayed data contradicts known cluster state
## Artifact Requirements
For each plugin tested, the UAT report must include:
1. **Screenshots** of the plugin running in Headlamp — sidebar entry visible, main view loaded, at least one detail view
2. **Test checklist** — each step from the playbook marked pass/fail
2. **Test checklist** — each step from `UAT_PLAYBOOK.md` marked pass/fail
3. **Console errors** — any browser console errors observed (attach screenshot if present)
4. **Environment** — Headlamp version, plugin version, browser used
4. **Environment info** — Headlamp version, plugin version, browser used, namespace context
## Reading UAT_PLAYBOOK.md
Each plugin repository contains a `UAT_PLAYBOOK.md` in its root directory. That file contains the canonical test steps for that specific plugin. Before running UAT, read the relevant playbook to know:
- Which features to exercise
- What the expected results are
- What screenshots to capture at each step
If `UAT_PLAYBOOK.md` does not exist for a plugin, treat that as a gap — report it in the UAT findings and flag it as a documentation issue.
## Decision Criteria
- **Approve** the `uat→main` PR when all applicable test steps pass
- **Request changes** with specific failing steps and failure screenshots
- **Block** if the plugin fails to load entirely — escalate to CTO as a deployment issue
- **Approve** the `uat→main` promotion when all applicable test steps from the playbook pass and no console errors are present
- **Request changes** when any test step fails — include specific failing steps, observed results vs. expected results, and failure screenshots
- **Block** if the plugin fails to load entirely — escalate to CTO as a deployment issue requiring immediate resolution