diff --git a/.apm/prompts/sippy-generate-release-views.prompt.md b/.apm/prompts/sippy-generate-release-views.prompt.md index eb2794764..27b4085eb 100644 --- a/.apm/prompts/sippy-generate-release-views.prompt.md +++ b/.apm/prompts/sippy-generate-release-views.prompt.md @@ -5,6 +5,8 @@ input: [source-release, target-release] # Generate Release Views +> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + This command generates new component readiness views for a new release by copying and updating existing views from a previous release. ## Arguments (all optional) @@ -37,7 +39,7 @@ If any arguments are not provided, you will prompt the user interactively. - **Base Release**: - If base = sample (same-release comparison), both become target - If base != sample (cross-release comparison), increment base by one minor version - - **IMPORTANT**: When base becomes source release, replace 'ga' with 'now' in relative_start and relative_end + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` 5. **Verify Output**: Show a diff of the changes made to views.yaml @@ -56,7 +58,7 @@ When copying a view from source release to target release: 3. **Base Release Update**: Depends on the original relationship - **Same-release views** (base = sample): Both become target - **Cross-release views** (base != sample): Base increments by one - - **CRITICAL**: When base becomes source release, replace 'ga' with 'now' in relative dates + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` ## Examples diff --git a/.apm/prompts/sippy-update-ga-release-views.prompt.md b/.apm/prompts/sippy-update-ga-release-views.prompt.md index 5bbac6b10..e5a16244e 100644 --- a/.apm/prompts/sippy-update-ga-release-views.prompt.md +++ b/.apm/prompts/sippy-update-ga-release-views.prompt.md @@ -44,8 +44,6 @@ If the argument is not provided, you will prompt the user interactively. **F. Decrease pass_rate_required_new_tests**: - Set `pass_rate_required_new_tests` to `90` (from 95) - - **IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) - 4. **Verify Output**: Show a diff of the changes made to views.yaml 5. **Run Validation Test**: @@ -71,3 +69,5 @@ This command is part of the release lifecycle workflow: - Use the Edit tool for each change to preserve exact YAML formatting - Always verify the diff to ensure only expected changes were made - This is typically run once when a release goes GA + +**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) diff --git a/.apm/prompts/sippy-update-job-variant.prompt.md b/.apm/prompts/sippy-update-job-variant.prompt.md index 84dc45ed2..d958e6359 100644 --- a/.apm/prompts/sippy-update-job-variant.prompt.md +++ b/.apm/prompts/sippy-update-job-variant.prompt.md @@ -50,8 +50,8 @@ You will guide the user through the following steps (skipping steps where argume - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.) - Add an entry to the pattern matching logic in that function with the pattern and new value - Follow the existing code style and pattern structure (see examples in the file) - - **CRITICAL**: Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. - - More specific patterns MUST come before more generic patterns + - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. + - More specific patterns come before more generic patterns - Example: In `setPlatform`, "-rosa" must come before "-aws" because ROSA jobs contain "aws" - Example: In `setOwner`, "-perfscale" must come before "-qe" because perfscale jobs may contain "qe" - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point @@ -78,16 +78,6 @@ You will guide the user through the following steps (skipping steps where argume - Always commit both the Go code changes AND the regenerated snapshot.yaml - Pattern matching is done with `strings.Contains(jobNameLower, pattern)` -### Pattern Ordering is CRITICAL -- **The setter functions use early return - the FIRST matching pattern wins** -- More specific patterns MUST appear before more generic patterns -- Common examples to learn from: - - `-rosa` before `-aws` (ROSA jobs contain "aws") - - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") - - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") - - `-perfscale` before `-qe` (perfscale jobs may contain "qe") -- Always verify the diff doesn't show unintended changes to other jobs - ## Helper Commands ### Extracting Variant Categories @@ -109,3 +99,13 @@ go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "S ```bash grep -E "^func set[A-Z]" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort ``` + +### Pattern Ordering is CRITICAL +- **The setter functions use early return - the FIRST matching pattern wins** +- More specific patterns MUST appear before more generic patterns +- Common examples to learn from: + - `-rosa` before `-aws` (ROSA jobs contain "aws") + - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") + - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") + - `-perfscale` before `-qe` (perfscale jobs may contain "qe") +- Always verify the diff doesn't show unintended changes to other jobs diff --git a/.claude/commands/sippy-generate-release-views.md b/.claude/commands/sippy-generate-release-views.md index 88e270fbb..4737cda7d 100644 --- a/.claude/commands/sippy-generate-release-views.md +++ b/.claude/commands/sippy-generate-release-views.md @@ -1,9 +1,15 @@ --- +argument-hint: +arguments: +- source-release +- target-release description: Generate new component readiness views for a new release --- # Generate Release Views +> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + This command generates new component readiness views for a new release by copying and updating existing views from a previous release. ## Arguments (all optional) @@ -36,7 +42,7 @@ If any arguments are not provided, you will prompt the user interactively. - **Base Release**: - If base = sample (same-release comparison), both become target - If base != sample (cross-release comparison), increment base by one minor version - - **IMPORTANT**: When base becomes source release, replace 'ga' with 'now' in relative_start and relative_end + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` 5. **Verify Output**: Show a diff of the changes made to views.yaml @@ -55,7 +61,7 @@ When copying a view from source release to target release: 3. **Base Release Update**: Depends on the original relationship - **Same-release views** (base = sample): Both become target - **Cross-release views** (base != sample): Base increments by one - - **CRITICAL**: When base becomes source release, replace 'ga' with 'now' in relative dates + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` ## Examples diff --git a/.claude/commands/sippy-update-ga-release-views.md b/.claude/commands/sippy-update-ga-release-views.md index 0a737a518..15b5aa6c4 100644 --- a/.claude/commands/sippy-update-ga-release-views.md +++ b/.claude/commands/sippy-update-ga-release-views.md @@ -1,4 +1,7 @@ --- +argument-hint: +arguments: +- release description: Update component readiness views when a release goes GA --- @@ -43,8 +46,6 @@ If the argument is not provided, you will prompt the user interactively. **F. Decrease pass_rate_required_new_tests**: - Set `pass_rate_required_new_tests` to `90` (from 95) - - **IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) - 4. **Verify Output**: Show a diff of the changes made to views.yaml 5. **Run Validation Test**: @@ -69,4 +70,6 @@ This command is part of the release lifecycle workflow: - Views where `sample_release.release` equals the GA release (sensitivity reductions) - Use the Edit tool for each change to preserve exact YAML formatting - Always verify the diff to ensure only expected changes were made -- This is typically run once when a release goes GA \ No newline at end of file +- This is typically run once when a release goes GA + +**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) \ No newline at end of file diff --git a/.claude/commands/sippy-update-job-variant.md b/.claude/commands/sippy-update-job-variant.md index f5e0ab057..0c5dad130 100644 --- a/.claude/commands/sippy-update-job-variant.md +++ b/.claude/commands/sippy-update-job-variant.md @@ -1,4 +1,9 @@ --- +argument-hint: +arguments: +- job-pattern +- category +- value description: Interactively update variants for a CI job --- @@ -49,8 +54,8 @@ You will guide the user through the following steps (skipping steps where argume - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.) - Add an entry to the pattern matching logic in that function with the pattern and new value - Follow the existing code style and pattern structure (see examples in the file) - - **CRITICAL**: Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. - - More specific patterns MUST come before more generic patterns + - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. + - More specific patterns come before more generic patterns - Example: In `setPlatform`, "-rosa" must come before "-aws" because ROSA jobs contain "aws" - Example: In `setOwner`, "-perfscale" must come before "-qe" because perfscale jobs may contain "qe" - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point @@ -77,16 +82,6 @@ You will guide the user through the following steps (skipping steps where argume - Always commit both the Go code changes AND the regenerated snapshot.yaml - Pattern matching is done with `strings.Contains(jobNameLower, pattern)` -### Pattern Ordering is CRITICAL -- **The setter functions use early return - the FIRST matching pattern wins** -- More specific patterns MUST appear before more generic patterns -- Common examples to learn from: - - `-rosa` before `-aws` (ROSA jobs contain "aws") - - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") - - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") - - `-perfscale` before `-qe` (perfscale jobs may contain "qe") -- Always verify the diff doesn't show unintended changes to other jobs - ## Helper Commands ### Extracting Variant Categories @@ -107,4 +102,14 @@ go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "S ### Finding Setter Functions ```bash grep -E "^func set[A-Z]" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort -``` \ No newline at end of file +``` + +### Pattern Ordering is CRITICAL +- **The setter functions use early return - the FIRST matching pattern wins** +- More specific patterns MUST appear before more generic patterns +- Common examples to learn from: + - `-rosa` before `-aws` (ROSA jobs contain "aws") + - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") + - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") + - `-perfscale` before `-qe` (perfscale jobs may contain "qe") +- Always verify the diff doesn't show unintended changes to other jobs \ No newline at end of file diff --git a/.coderabbit.yaml b/.coderabbit.yaml index ba56755e4..a211f683b 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -37,7 +37,7 @@ reviews: explaining the purpose of each major query section (CTEs, JOINs, window functions, WHERE clauses). Abbreviations like CTE, matview, etc. should be expanded on first use. Functions that construct queries - should ideally stay under 200 lines; extract sub-queries or CTEs into + must stay under 200 lines; extract sub-queries or CTEs into helper functions when they grow beyond that. - path: "pkg/apis/**/*.go" instructions: | @@ -105,7 +105,7 @@ reviews: - name: "Test Coverage for New Features" mode: warning instructions: | - New or modified functionality should include test coverage where possible: + New or modified functionality must include test coverage: - New Go functions and methods should have corresponding unit tests - Bug fixes should include a regression test that fails without the fix - Pure functions (no DB/external dependencies) should always be tested diff --git a/.cursor/commands/sippy-dev-app.md b/.cursor/commands/sippy-dev-app.md new file mode 100644 index 000000000..85d2be678 --- /dev/null +++ b/.cursor/commands/sippy-dev-app.md @@ -0,0 +1,12 @@ +--- +description: Start both Sippy backend and frontend dev servers +--- + +# Sippy dev — backend + frontend + +Start the full local Sippy stack using two MCP tool calls (server: **`sippy-dev`**). Run them in order — backend first, then frontend. + +1. **`sippy_serve`** — pass **`bigquery_credentials_file`** when `SIPPY_BIGQUERY_CREDENTIALS_FILE` / `GOOGLE_APPLICATION_CREDENTIALS` are not set. +2. **`sippy_ng_start`** + +Each tool returns listen hints (typically **8080** / **3000**) and log paths. If a tool reports already running, ask the user if they want to restart it. If yes, call the tool again with **`restart=True`**. \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-frontend.md b/.cursor/commands/sippy-dev-frontend.md new file mode 100644 index 000000000..53b16d603 --- /dev/null +++ b/.cursor/commands/sippy-dev-frontend.md @@ -0,0 +1,13 @@ +--- +description: Start the sippy-ng React dev server via the sippy-dev MCP tool +--- + +# Sippy dev — frontend (sippy-ng) + +Use the **`sippy_ng_start`** MCP tool (server: **`sippy-dev`**). Do not run `npm start` in `sippy-ng` manually — the MCP tool handles background process management, log routing, and duplicate detection. + +**`open_browser`** defaults to **`false`**. Typical URL: **`http://127.0.0.1:3000`**. Log: **`sippy-dev-logs/sippy_ng_start.log`**. + +If the dev server is already running, the tool will report it. Ask the user if they want to restart, and if so call again with **`restart=True`**. + +See **`mcp/server.py`** for all parameters. \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-migrate.md b/.cursor/commands/sippy-dev-migrate.md new file mode 100644 index 000000000..2430ba319 --- /dev/null +++ b/.cursor/commands/sippy-dev-migrate.md @@ -0,0 +1,17 @@ +--- +description: Run Sippy PostgreSQL schema migration +--- + +# Sippy dev — migrate + +Run the migration command directly: + +```bash +go run ./cmd/sippy migrate --database-dsn "$SIPPY_DATABASE_DSN" +``` + +If `SIPPY_DATABASE_DSN` is not set, use the dev default: + +```bash +go run ./cmd/sippy migrate --database-dsn "postgresql://postgres:password@localhost:5432/postgres" +``` \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-regression-cache.md b/.cursor/commands/sippy-dev-regression-cache.md new file mode 100644 index 000000000..0ca7f4d75 --- /dev/null +++ b/.cursor/commands/sippy-dev-regression-cache.md @@ -0,0 +1,11 @@ +--- +description: Run the Sippy regression-cache loader (BigQuery + Redis + DB) +--- + +# Sippy dev — regression-cache + +Use the **`regression_cache`** MCP tool (server: **`sippy-dev`**). Do not run `go run ./cmd/sippy load --loader regression-cache` manually — the MCP tool handles credentials, logging, and timeouts. + +**`bigquery_credentials_file`**: path to BigQuery-capable SA JSON (e.g. `sippy-bigquery-job-importer-key.json`); optional if `SIPPY_BIGQUERY_CREDENTIALS_FILE` or `GOOGLE_APPLICATION_CREDENTIALS` is set. + +See **`mcp/server.py`** for all parameters. Log: **`sippy-dev-logs/regression_cache.log`**. Typical duration is many minutes. \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-serve.md b/.cursor/commands/sippy-dev-serve.md new file mode 100644 index 000000000..efda397cd --- /dev/null +++ b/.cursor/commands/sippy-dev-serve.md @@ -0,0 +1,13 @@ +--- +description: Start the Sippy HTTP API server via the sippy-dev MCP tool +--- + +# Sippy dev — serve + +Use the **`sippy_serve`** MCP tool (server: **`sippy-dev`**). Do not run `go run ./cmd/sippy serve` manually — the MCP tool handles background process management, log routing, and duplicate detection. + +The default **`data_provider`** is `"postgres"`, which uses seed data and **does not require BigQuery credentials**. Set `data_provider="bigquery"` and provide **`bigquery_credentials_file`** to use BigQuery instead. + +If the server is already running, the tool will report it. Ask the user if they want to restart, and if so call again with **`restart=True`**. + +See **`mcp/server.py`** for all parameters. Typical listen address: **`:8080`**. Log: **`sippy-dev-logs/sippy_serve.log`**. \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-setup.md b/.cursor/commands/sippy-dev-setup.md new file mode 100644 index 000000000..0e4f11dd4 --- /dev/null +++ b/.cursor/commands/sippy-dev-setup.md @@ -0,0 +1,113 @@ +--- +description: Set up the Sippy devcontainer (Podman, env, GCP auth) +--- + +# Sippy dev — devcontainer setup + +Interactive setup for the Sippy devcontainer. Automates what can be detected, prompts for what can't. + +## Workflow + +### 1. Detect OS + +```bash +uname -s +``` + +- **Darwin** = macOS +- **Linux** = Linux + +### 2. Check prerequisites + +Verify each tool is installed. Report any that are missing and stop. + +```bash +command -v podman +command -v devcontainer +``` + +If `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli` + +### 3. macOS: Podman machine + +If macOS, check if podman machine is running: + +```bash +podman machine info +``` + +If not initialized or not running, run: + +```bash +podman machine init # only if no machine exists +podman machine start +``` + +### 4. Linux: Podman socket + +If Linux, check if the socket is active: + +```bash +systemctl --user is-active podman.socket +``` + +If not active, run: + +```bash +systemctl --user enable --now podman.socket +``` + +Also check for `podman-docker`: + +```bash +command -v docker +``` + +If missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`). + +### 5. Environment file + +Check if `.devcontainer/.env` exists: + +```bash +test -f .devcontainer/.env +``` + +If missing, copy from the example: + +```bash +cp .devcontainer/.env.example .devcontainer/.env +``` + +Then read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing. + +### 6. Start the container + +Determine the right command based on OS: + +- **macOS**: `devcontainer up --workspace-folder . --docker-path podman` +- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .` +- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman` + +Run it. This triggers `init-services.sh` (PostgreSQL + Redis) and `post-create.sh` (Go tools, npm, MCP venv). + +### 7. GCP authentication + +GCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container): + +```bash +gcloud auth application-default login +``` + +The credentials will be available inside the container automatically after restart. + +### 8. Summary + +Print a summary of what was set up: + +- Container status +- PostgreSQL: `localhost:5432` +- Redis: `localhost:6379` +- API server: `localhost:8080` (start with `/sippy-dev-serve`) +- React dev server: `localhost:3000` (start with `/sippy-dev-frontend`) +- GCP auth status \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-tests.md b/.cursor/commands/sippy-dev-tests.md new file mode 100644 index 000000000..228c69740 --- /dev/null +++ b/.cursor/commands/sippy-dev-tests.md @@ -0,0 +1,29 @@ +--- +description: Run lint, unit tests, and e2e in order (full local CI suite) +--- + +# Sippy dev — full test suite + +Run these three steps in order. Stop if any step fails. + +1. **Lint** — run directly: + + ```bash + CI=true make lint + ``` + + `CI=true` makes `hack/go-lint.sh` use the locally installed `golangci-lint` instead of spawning a container. + +2. **Unit tests** — run directly: + + ```bash + make test + ``` + +3. **E2e** — run directly: + + ```bash + make e2e + ``` + + Works both on the host (starts its own PostgreSQL/Redis containers via Podman) and inside the devcontainer (creates a temporary `sippy_e2e` database on the existing PostgreSQL). \ No newline at end of file diff --git a/.cursor/commands/sippy-generate-release-views.md b/.cursor/commands/sippy-generate-release-views.md new file mode 100644 index 000000000..4737cda7d --- /dev/null +++ b/.cursor/commands/sippy-generate-release-views.md @@ -0,0 +1,79 @@ +--- +argument-hint: +arguments: +- source-release +- target-release +description: Generate new component readiness views for a new release +--- + +# Generate Release Views + +> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + +This command generates new component readiness views for a new release by copying and updating existing views from a previous release. + +## Arguments (all optional) + +- `[source-release]`: Source release version to copy views from (e.g., `4.21`) +- `[target-release]`: Target release version to create views for (e.g., `4.22`) + +If any arguments are not provided, you will prompt the user interactively. + +## Workflow + +1. **Prompt for Source Release**: Ask the user for the source release version (e.g., `4.21`) + - Format must be X.Y (e.g., 4.21, 4.20) + +2. **Prompt for Target Release**: Ask the user for the target release version (e.g., `4.22`) + - Format must be X.Y (e.g., 4.22, 4.23) + +3. **Preview Changes**: Run the script in preview mode: + - Execute: `python3 scripts/generate_release_views.py ` + - Ask for confirmation before proceeding + +4. **Apply Changes**: If confirmed, run with --apply flag: + - Execute: `python3 scripts/generate_release_views.py --apply` + - The script will: + - Read `config/views.yaml` + - Find all views where `sample_release.release` equals the source release + - Create new views with updated releases and add them to the TOP of the views list + - **Name**: Replace source release with target release + - **Sample Release**: Update to target release + - **Base Release**: + - If base = sample (same-release comparison), both become target + - If base != sample (cross-release comparison), increment base by one minor version + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + +5. **Verify Output**: Show a diff of the changes made to views.yaml + +6. **Run Validation Test**: + - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/` + - If the test fails, the views.yaml has errors that must be fixed before committing + +7. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master). + +## View Update Logic + +When copying a view from source release to target release: + +1. **Name Update**: Replace all occurrences of source release in the name +2. **Sample Release Update**: Always set to target release +3. **Base Release Update**: Depends on the original relationship + - **Same-release views** (base = sample): Both become target + - **Cross-release views** (base != sample): Base increments by one + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + +## Examples + +### Creating 4.22 views from 4.21 + +- `4.21-main` (base: 4.20, sample: 4.21) -> `4.22-main` (base: 4.21, sample: 4.22) + - `relative_start: "ga-30d"` -> `relative_start: "now-30d"` (because base now references 4.21) +- `4.21-x86-vs-multi-arm` (base: 4.21, sample: 4.21) -> `4.22-x86-vs-multi-arm` (base: 4.22, sample: 4.22) + +## Important Notes + +- The script preserves all other view settings (variant_options, advanced_options, etc.) +- Release versions must be in format X.Y (e.g., 4.21) +- YAML formatting should be preserved using proper YAML libraries +- Always verify the diff before committing \ No newline at end of file diff --git a/.cursor/commands/sippy-update-ga-release-views.md b/.cursor/commands/sippy-update-ga-release-views.md new file mode 100644 index 000000000..15b5aa6c4 --- /dev/null +++ b/.cursor/commands/sippy-update-ga-release-views.md @@ -0,0 +1,75 @@ +--- +argument-hint: +arguments: +- release +description: Update component readiness views when a release goes GA +--- + +# Update GA Release Views + +This command updates component readiness views when a release goes GA by converting 'now' references to 'ga' in base_release relative dates and reducing sensitivity parameters. + +## Arguments (optional) + +- `[release]`: Release version that just went GA (e.g., `4.21`) + +If the argument is not provided, you will prompt the user interactively. + +## Workflow + +1. **Prompt for GA Release**: Ask the user which release just went GA (e.g., `4.21`) + - Format must be X.Y (e.g., 4.21, 4.20) + +2. **Find Affected Views**: Search config/views.yaml to identify affected views: + - Views where `base_release.release` equals the GA release (for date updates) + - Views where `sample_release.release` equals the GA release (for sensitivity reductions) + - Show the user the affected views and ask for confirmation + +3. **Apply Updates**: For each affected view: + + **A. Update base_release dates** (views comparing newer releases to the GA release): + - Replace 'now' with 'ga' in `relative_start` (e.g., `now-30d` -> `ga-30d`) + - Replace 'now' with 'ga' in `relative_end` (e.g., `now` -> `ga`) + + **B. Disable automate_jira** (views of the GA release itself): + - Change `automate_jira.enabled` from `true` to `false` + + **C. Disable multi-release analysis**: + - Change `include_multi_release_analysis` from `true` to `false` + + **D. Increase pity_factor**: + - Set `pity_factor` to `10` (from 5) + + **E. Increase minimum_failure**: + - Set `minimum_failure` to `4` (from 3) + + **F. Decrease pass_rate_required_new_tests**: + - Set `pass_rate_required_new_tests` to `90` (from 95) + +4. **Verify Output**: Show a diff of the changes made to views.yaml + +5. **Run Validation Test**: + - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/` + +6. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master). + +## Use Case + +This command is part of the release lifecycle workflow: + +1. **Before GA**: New release (e.g., 4.22) is created with views comparing to previous release (4.21) + - Views use `base_release: {release: "4.21", relative_start: "now-30d", relative_end: "now"}` +2. **When 4.21 goes GA**: Run this command + - Changes to `base_release: {release: "4.21", relative_start: "ga-30d", relative_end: "ga"}` + - Reduces sensitivity for the GA release's own views + +## Important Notes + +- This command affects two sets of views: + - Views where `base_release.release` equals the GA release (date updates) + - Views where `sample_release.release` equals the GA release (sensitivity reductions) +- Use the Edit tool for each change to preserve exact YAML formatting +- Always verify the diff to ensure only expected changes were made +- This is typically run once when a release goes GA + +**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) \ No newline at end of file diff --git a/.cursor/commands/sippy-update-job-variant.md b/.cursor/commands/sippy-update-job-variant.md new file mode 100644 index 000000000..0c5dad130 --- /dev/null +++ b/.cursor/commands/sippy-update-job-variant.md @@ -0,0 +1,115 @@ +--- +argument-hint: +arguments: +- job-pattern +- category +- value +description: Interactively update variants for a CI job +--- + +# Update Job Variant + +This command provides an interactive workflow to update variant assignments for CI jobs by modifying the variant registry Go code. + +## Arguments (all optional) + +- `[job-pattern]`: Pattern (substring or full job name) that identifies the CI job(s) to update (e.g., `-hypershift-`, `-metal-ipi-`, or full job name like `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`) +- `[category]`: Variant category to update (e.g., Platform, Architecture, Topology) +- `[value]`: New value to set for the variant category + +If any arguments are not provided, you will prompt the user interactively. + +## Workflow + +**IMPORTANT: Argument Parsing** +Before starting the workflow, check if the user provided any arguments: + +1. Parse the command invocation to extract any provided arguments +2. If all three arguments (job-pattern, category, value) are provided: + - Validate the category exists in the snapshot file + - Skip the corresponding prompting steps + - Use the provided values directly +3. If some arguments are missing, prompt only for the missing ones +4. If no arguments are provided, follow the full interactive workflow below + +You will guide the user through the following steps (skipping steps where arguments were provided): + +1. **Prompt for a Job Pattern**: Ask the user to enter a pattern that identifies the CI job(s) they want to update. This can be either a full job name or a substring. This will be used to add pattern matching logic to the Go code. + - Example full job name: `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn` + - Example substrings: `-hypershift-`, `-metal-ipi-`, `-fips-` + - **Important**: Both full job names and substrings are acceptable. Accept whatever the user provides without asking for clarification. + - Advise the user that more specific patterns avoid unintended matches (e.g., `-metal-ipi-ovn-ipv6-` instead of just `-metal-`) + +2. **Select Variant Category**: Extract variant categories programmatically and present as a numbered list: + - Run: `grep -E "^ [A-Z]" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u` + - This extracts all unique variant categories from the snapshot file + - Present the list with numbers (1, 2, 3, etc.) and ask the user to select by number + +3. **Select New Value**: Based on the chosen category, extract possible values programmatically and present as a numbered list: + - For most categories, extract values from the snapshot: `grep "^ :" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/"//g' | sort -u` + - Present the unique values as a numbered list and ask the user to select by number + - For Release-related variants (Release, FromRelease, FromReleaseMajor, FromReleaseMinor, ReleaseMajor, ReleaseMinor), allow free-text input instead of showing a numbered list + +4. **Modify the Go Code**: Update `pkg/variantregistry/ocp.go` to add the pattern matching logic: + - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.) + - Add an entry to the pattern matching logic in that function with the pattern and new value + - Follow the existing code style and pattern structure (see examples in the file) + - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. + - More specific patterns come before more generic patterns + - Example: In `setPlatform`, "-rosa" must come before "-aws" because ROSA jobs contain "aws" + - Example: In `setOwner`, "-perfscale" must come before "-qe" because perfscale jobs may contain "qe" + - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point + - Check if the new pattern might overlap with existing patterns and ensure correct precedence + +5. **Preview Changes with Test**: Run the variant snapshot test to see what will change: + - Execute: `go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "Summary of changes:"` + - Parse this output to extract the variant category changed, old/new values, affected jobs, and total count + - Display the summary to the user + +6. **Apply Changes**: Execute `make update-variants` to regenerate `pkg/variantregistry/snapshot.yaml` + +7. **Verify Unintended Changes** (optional manual step): + - Suggest the user review `git diff pkg/variantregistry/snapshot.yaml` to ensure only expected jobs changed + +8. **Offer to Commit**: Ask the user if they want to commit the changes. If yes, commit both the Go code and the regenerated snapshot. + +## Important Notes + +- The variant logic is defined in `pkg/variantregistry/ocp.go` in setter functions +- Each variant category has its own setter function with a pattern matching list +- The `make update-variants` command runs `./sippy variants snapshot --config ./config/openshift.yaml` +- This regenerates `pkg/variantregistry/snapshot.yaml` based on the Go code logic +- Always commit both the Go code changes AND the regenerated snapshot.yaml +- Pattern matching is done with `strings.Contains(jobNameLower, pattern)` + +## Helper Commands + +### Extracting Variant Categories +```bash +grep -E "^ [A-Z]" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u +``` + +### Extracting Values for a Specific Category +```bash +grep "^ :" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/"//g' | sort -u +``` + +### Previewing Changes +```bash +go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "Summary of changes:" +``` + +### Finding Setter Functions +```bash +grep -E "^func set[A-Z]" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort +``` + +### Pattern Ordering is CRITICAL +- **The setter functions use early return - the FIRST matching pattern wins** +- More specific patterns MUST appear before more generic patterns +- Common examples to learn from: + - `-rosa` before `-aws` (ROSA jobs contain "aws") + - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") + - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") + - `-perfscale` before `-qe` (perfscale jobs may contain "qe") +- Always verify the diff doesn't show unintended changes to other jobs \ No newline at end of file diff --git a/.gemini/commands/sippy-generate-release-views.toml b/.gemini/commands/sippy-generate-release-views.toml index d381e0f5c..a94fbe27c 100644 --- a/.gemini/commands/sippy-generate-release-views.toml +++ b/.gemini/commands/sippy-generate-release-views.toml @@ -1,2 +1,2 @@ description = "Generate new component readiness views for a new release" -prompt = "# Generate Release Views\n\nThis command generates new component readiness views for a new release by copying and updating existing views from a previous release.\n\n## Arguments (all optional)\n\n- `[source-release]`: Source release version to copy views from (e.g., `4.21`)\n- `[target-release]`: Target release version to create views for (e.g., `4.22`)\n\nIf any arguments are not provided, you will prompt the user interactively.\n\n## Workflow\n\n1. **Prompt for Source Release**: Ask the user for the source release version (e.g., `4.21`)\n - Format must be X.Y (e.g., 4.21, 4.20)\n\n2. **Prompt for Target Release**: Ask the user for the target release version (e.g., `4.22`)\n - Format must be X.Y (e.g., 4.22, 4.23)\n\n3. **Preview Changes**: Run the script in preview mode:\n - Execute: `python3 scripts/generate_release_views.py `\n - Ask for confirmation before proceeding\n\n4. **Apply Changes**: If confirmed, run with --apply flag:\n - Execute: `python3 scripts/generate_release_views.py --apply`\n - The script will:\n - Read `config/views.yaml`\n - Find all views where `sample_release.release` equals the source release\n - Create new views with updated releases and add them to the TOP of the views list\n - **Name**: Replace source release with target release\n - **Sample Release**: Update to target release\n - **Base Release**:\n - If base = sample (same-release comparison), both become target\n - If base != sample (cross-release comparison), increment base by one minor version\n - **IMPORTANT**: When base becomes source release, replace 'ga' with 'now' in relative_start and relative_end\n\n5. **Verify Output**: Show a diff of the changes made to views.yaml\n\n6. **Run Validation Test**:\n - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/`\n - If the test fails, the views.yaml has errors that must be fixed before committing\n\n7. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master).\n\n## View Update Logic\n\nWhen copying a view from source release to target release:\n\n1. **Name Update**: Replace all occurrences of source release in the name\n2. **Sample Release Update**: Always set to target release\n3. **Base Release Update**: Depends on the original relationship\n - **Same-release views** (base = sample): Both become target\n - **Cross-release views** (base != sample): Base increments by one\n - **CRITICAL**: When base becomes source release, replace 'ga' with 'now' in relative dates\n\n## Examples\n\n### Creating 4.22 views from 4.21\n\n- `4.21-main` (base: 4.20, sample: 4.21) -> `4.22-main` (base: 4.21, sample: 4.22)\n - `relative_start: \"ga-30d\"` -> `relative_start: \"now-30d\"` (because base now references 4.21)\n- `4.21-x86-vs-multi-arm` (base: 4.21, sample: 4.21) -> `4.22-x86-vs-multi-arm` (base: 4.22, sample: 4.22)\n\n## Important Notes\n\n- The script preserves all other view settings (variant_options, advanced_options, etc.)\n- Release versions must be in format X.Y (e.g., 4.21)\n- YAML formatting should be preserved using proper YAML libraries\n- Always verify the diff before committing" +prompt = "# Generate Release Views\n\n> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end`\n\nThis command generates new component readiness views for a new release by copying and updating existing views from a previous release.\n\n## Arguments (all optional)\n\n- `[source-release]`: Source release version to copy views from (e.g., `4.21`)\n- `[target-release]`: Target release version to create views for (e.g., `4.22`)\n\nIf any arguments are not provided, you will prompt the user interactively.\n\n## Workflow\n\n1. **Prompt for Source Release**: Ask the user for the source release version (e.g., `4.21`)\n - Format must be X.Y (e.g., 4.21, 4.20)\n\n2. **Prompt for Target Release**: Ask the user for the target release version (e.g., `4.22`)\n - Format must be X.Y (e.g., 4.22, 4.23)\n\n3. **Preview Changes**: Run the script in preview mode:\n - Execute: `python3 scripts/generate_release_views.py `\n - Ask for confirmation before proceeding\n\n4. **Apply Changes**: If confirmed, run with --apply flag:\n - Execute: `python3 scripts/generate_release_views.py --apply`\n - The script will:\n - Read `config/views.yaml`\n - Find all views where `sample_release.release` equals the source release\n - Create new views with updated releases and add them to the TOP of the views list\n - **Name**: Replace source release with target release\n - **Sample Release**: Update to target release\n - **Base Release**:\n - If base = sample (same-release comparison), both become target\n - If base != sample (cross-release comparison), increment base by one minor version\n - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end`\n\n5. **Verify Output**: Show a diff of the changes made to views.yaml\n\n6. **Run Validation Test**:\n - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/`\n - If the test fails, the views.yaml has errors that must be fixed before committing\n\n7. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master).\n\n## View Update Logic\n\nWhen copying a view from source release to target release:\n\n1. **Name Update**: Replace all occurrences of source release in the name\n2. **Sample Release Update**: Always set to target release\n3. **Base Release Update**: Depends on the original relationship\n - **Same-release views** (base = sample): Both become target\n - **Cross-release views** (base != sample): Base increments by one\n - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end`\n\n## Examples\n\n### Creating 4.22 views from 4.21\n\n- `4.21-main` (base: 4.20, sample: 4.21) -> `4.22-main` (base: 4.21, sample: 4.22)\n - `relative_start: \"ga-30d\"` -> `relative_start: \"now-30d\"` (because base now references 4.21)\n- `4.21-x86-vs-multi-arm` (base: 4.21, sample: 4.21) -> `4.22-x86-vs-multi-arm` (base: 4.22, sample: 4.22)\n\n## Important Notes\n\n- The script preserves all other view settings (variant_options, advanced_options, etc.)\n- Release versions must be in format X.Y (e.g., 4.21)\n- YAML formatting should be preserved using proper YAML libraries\n- Always verify the diff before committing" diff --git a/.gemini/commands/sippy-update-ga-release-views.toml b/.gemini/commands/sippy-update-ga-release-views.toml index c3ce8645b..5d69b95bc 100644 --- a/.gemini/commands/sippy-update-ga-release-views.toml +++ b/.gemini/commands/sippy-update-ga-release-views.toml @@ -1,2 +1,2 @@ description = "Update component readiness views when a release goes GA" -prompt = "# Update GA Release Views\n\nThis command updates component readiness views when a release goes GA by converting 'now' references to 'ga' in base_release relative dates and reducing sensitivity parameters.\n\n## Arguments (optional)\n\n- `[release]`: Release version that just went GA (e.g., `4.21`)\n\nIf the argument is not provided, you will prompt the user interactively.\n\n## Workflow\n\n1. **Prompt for GA Release**: Ask the user which release just went GA (e.g., `4.21`)\n - Format must be X.Y (e.g., 4.21, 4.20)\n\n2. **Find Affected Views**: Search config/views.yaml to identify affected views:\n - Views where `base_release.release` equals the GA release (for date updates)\n - Views where `sample_release.release` equals the GA release (for sensitivity reductions)\n - Show the user the affected views and ask for confirmation\n\n3. **Apply Updates**: For each affected view:\n\n **A. Update base_release dates** (views comparing newer releases to the GA release):\n - Replace 'now' with 'ga' in `relative_start` (e.g., `now-30d` -> `ga-30d`)\n - Replace 'now' with 'ga' in `relative_end` (e.g., `now` -> `ga`)\n\n **B. Disable automate_jira** (views of the GA release itself):\n - Change `automate_jira.enabled` from `true` to `false`\n\n **C. Disable multi-release analysis**:\n - Change `include_multi_release_analysis` from `true` to `false`\n\n **D. Increase pity_factor**:\n - Set `pity_factor` to `10` (from 5)\n\n **E. Increase minimum_failure**:\n - Set `minimum_failure` to `4` (from 3)\n\n **F. Decrease pass_rate_required_new_tests**:\n - Set `pass_rate_required_new_tests` to `90` (from 95)\n\n - **IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation)\n\n4. **Verify Output**: Show a diff of the changes made to views.yaml\n\n5. **Run Validation Test**:\n - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/`\n\n6. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master).\n\n## Use Case\n\nThis command is part of the release lifecycle workflow:\n\n1. **Before GA**: New release (e.g., 4.22) is created with views comparing to previous release (4.21)\n - Views use `base_release: {release: \"4.21\", relative_start: \"now-30d\", relative_end: \"now\"}`\n2. **When 4.21 goes GA**: Run this command\n - Changes to `base_release: {release: \"4.21\", relative_start: \"ga-30d\", relative_end: \"ga\"}`\n - Reduces sensitivity for the GA release's own views\n\n## Important Notes\n\n- This command affects two sets of views:\n - Views where `base_release.release` equals the GA release (date updates)\n - Views where `sample_release.release` equals the GA release (sensitivity reductions)\n- Use the Edit tool for each change to preserve exact YAML formatting\n- Always verify the diff to ensure only expected changes were made\n- This is typically run once when a release goes GA" +prompt = "# Update GA Release Views\n\nThis command updates component readiness views when a release goes GA by converting 'now' references to 'ga' in base_release relative dates and reducing sensitivity parameters.\n\n## Arguments (optional)\n\n- `[release]`: Release version that just went GA (e.g., `4.21`)\n\nIf the argument is not provided, you will prompt the user interactively.\n\n## Workflow\n\n1. **Prompt for GA Release**: Ask the user which release just went GA (e.g., `4.21`)\n - Format must be X.Y (e.g., 4.21, 4.20)\n\n2. **Find Affected Views**: Search config/views.yaml to identify affected views:\n - Views where `base_release.release` equals the GA release (for date updates)\n - Views where `sample_release.release` equals the GA release (for sensitivity reductions)\n - Show the user the affected views and ask for confirmation\n\n3. **Apply Updates**: For each affected view:\n\n **A. Update base_release dates** (views comparing newer releases to the GA release):\n - Replace 'now' with 'ga' in `relative_start` (e.g., `now-30d` -> `ga-30d`)\n - Replace 'now' with 'ga' in `relative_end` (e.g., `now` -> `ga`)\n\n **B. Disable automate_jira** (views of the GA release itself):\n - Change `automate_jira.enabled` from `true` to `false`\n\n **C. Disable multi-release analysis**:\n - Change `include_multi_release_analysis` from `true` to `false`\n\n **D. Increase pity_factor**:\n - Set `pity_factor` to `10` (from 5)\n\n **E. Increase minimum_failure**:\n - Set `minimum_failure` to `4` (from 3)\n\n **F. Decrease pass_rate_required_new_tests**:\n - Set `pass_rate_required_new_tests` to `90` (from 95)\n\n4. **Verify Output**: Show a diff of the changes made to views.yaml\n\n5. **Run Validation Test**:\n - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/`\n\n6. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master).\n\n## Use Case\n\nThis command is part of the release lifecycle workflow:\n\n1. **Before GA**: New release (e.g., 4.22) is created with views comparing to previous release (4.21)\n - Views use `base_release: {release: \"4.21\", relative_start: \"now-30d\", relative_end: \"now\"}`\n2. **When 4.21 goes GA**: Run this command\n - Changes to `base_release: {release: \"4.21\", relative_start: \"ga-30d\", relative_end: \"ga\"}`\n - Reduces sensitivity for the GA release's own views\n\n## Important Notes\n\n- This command affects two sets of views:\n - Views where `base_release.release` equals the GA release (date updates)\n - Views where `sample_release.release` equals the GA release (sensitivity reductions)\n- Use the Edit tool for each change to preserve exact YAML formatting\n- Always verify the diff to ensure only expected changes were made\n- This is typically run once when a release goes GA\n\n**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation)" diff --git a/.gemini/commands/sippy-update-job-variant.toml b/.gemini/commands/sippy-update-job-variant.toml index 2de3407dd..fbaf08227 100644 --- a/.gemini/commands/sippy-update-job-variant.toml +++ b/.gemini/commands/sippy-update-job-variant.toml @@ -1,2 +1,2 @@ description = "Interactively update variants for a CI job" -prompt = "# Update Job Variant\n\nThis command provides an interactive workflow to update variant assignments for CI jobs by modifying the variant registry Go code.\n\n## Arguments (all optional)\n\n- `[job-pattern]`: Pattern (substring or full job name) that identifies the CI job(s) to update (e.g., `-hypershift-`, `-metal-ipi-`, or full job name like `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`)\n- `[category]`: Variant category to update (e.g., Platform, Architecture, Topology)\n- `[value]`: New value to set for the variant category\n\nIf any arguments are not provided, you will prompt the user interactively.\n\n## Workflow\n\n**IMPORTANT: Argument Parsing**\nBefore starting the workflow, check if the user provided any arguments:\n\n1. Parse the command invocation to extract any provided arguments\n2. If all three arguments (job-pattern, category, value) are provided:\n - Validate the category exists in the snapshot file\n - Skip the corresponding prompting steps\n - Use the provided values directly\n3. If some arguments are missing, prompt only for the missing ones\n4. If no arguments are provided, follow the full interactive workflow below\n\nYou will guide the user through the following steps (skipping steps where arguments were provided):\n\n1. **Prompt for a Job Pattern**: Ask the user to enter a pattern that identifies the CI job(s) they want to update. This can be either a full job name or a substring. This will be used to add pattern matching logic to the Go code.\n - Example full job name: `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`\n - Example substrings: `-hypershift-`, `-metal-ipi-`, `-fips-`\n - **Important**: Both full job names and substrings are acceptable. Accept whatever the user provides without asking for clarification.\n - Advise the user that more specific patterns avoid unintended matches (e.g., `-metal-ipi-ovn-ipv6-` instead of just `-metal-`)\n\n2. **Select Variant Category**: Extract variant categories programmatically and present as a numbered list:\n - Run: `grep -E \"^ [A-Z]\" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u`\n - This extracts all unique variant categories from the snapshot file\n - Present the list with numbers (1, 2, 3, etc.) and ask the user to select by number\n\n3. **Select New Value**: Based on the chosen category, extract possible values programmatically and present as a numbered list:\n - For most categories, extract values from the snapshot: `grep \"^ :\" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/\"//g' | sort -u`\n - Present the unique values as a numbered list and ask the user to select by number\n - For Release-related variants (Release, FromRelease, FromReleaseMajor, FromReleaseMinor, ReleaseMajor, ReleaseMinor), allow free-text input instead of showing a numbered list\n\n4. **Modify the Go Code**: Update `pkg/variantregistry/ocp.go` to add the pattern matching logic:\n - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.)\n - Add an entry to the pattern matching logic in that function with the pattern and new value\n - Follow the existing code style and pattern structure (see examples in the file)\n - **CRITICAL**: Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins.\n - More specific patterns MUST come before more generic patterns\n - Example: In `setPlatform`, \"-rosa\" must come before \"-aws\" because ROSA jobs contain \"aws\"\n - Example: In `setOwner`, \"-perfscale\" must come before \"-qe\" because perfscale jobs may contain \"qe\"\n - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point\n - Check if the new pattern might overlap with existing patterns and ensure correct precedence\n\n5. **Preview Changes with Test**: Run the variant snapshot test to see what will change:\n - Execute: `go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 \"Summary of changes:\"`\n - Parse this output to extract the variant category changed, old/new values, affected jobs, and total count\n - Display the summary to the user\n\n6. **Apply Changes**: Execute `make update-variants` to regenerate `pkg/variantregistry/snapshot.yaml`\n\n7. **Verify Unintended Changes** (optional manual step):\n - Suggest the user review `git diff pkg/variantregistry/snapshot.yaml` to ensure only expected jobs changed\n\n8. **Offer to Commit**: Ask the user if they want to commit the changes. If yes, commit both the Go code and the regenerated snapshot.\n\n## Important Notes\n\n- The variant logic is defined in `pkg/variantregistry/ocp.go` in setter functions\n- Each variant category has its own setter function with a pattern matching list\n- The `make update-variants` command runs `./sippy variants snapshot --config ./config/openshift.yaml`\n- This regenerates `pkg/variantregistry/snapshot.yaml` based on the Go code logic\n- Always commit both the Go code changes AND the regenerated snapshot.yaml\n- Pattern matching is done with `strings.Contains(jobNameLower, pattern)`\n\n### Pattern Ordering is CRITICAL\n- **The setter functions use early return - the FIRST matching pattern wins**\n- More specific patterns MUST appear before more generic patterns\n- Common examples to learn from:\n - `-rosa` before `-aws` (ROSA jobs contain \"aws\")\n - `-azure-aro-hcp` before `-azure` (ARO jobs contain \"azure\")\n - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain \"gcp\")\n - `-perfscale` before `-qe` (perfscale jobs may contain \"qe\")\n- Always verify the diff doesn't show unintended changes to other jobs\n\n## Helper Commands\n\n### Extracting Variant Categories\n```bash\ngrep -E \"^ [A-Z]\" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u\n```\n\n### Extracting Values for a Specific Category\n```bash\ngrep \"^ :\" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/\"//g' | sort -u\n```\n\n### Previewing Changes\n```bash\ngo test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 \"Summary of changes:\"\n```\n\n### Finding Setter Functions\n```bash\ngrep -E \"^func set[A-Z]\" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort\n```" +prompt = "# Update Job Variant\n\nThis command provides an interactive workflow to update variant assignments for CI jobs by modifying the variant registry Go code.\n\n## Arguments (all optional)\n\n- `[job-pattern]`: Pattern (substring or full job name) that identifies the CI job(s) to update (e.g., `-hypershift-`, `-metal-ipi-`, or full job name like `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`)\n- `[category]`: Variant category to update (e.g., Platform, Architecture, Topology)\n- `[value]`: New value to set for the variant category\n\nIf any arguments are not provided, you will prompt the user interactively.\n\n## Workflow\n\n**IMPORTANT: Argument Parsing**\nBefore starting the workflow, check if the user provided any arguments:\n\n1. Parse the command invocation to extract any provided arguments\n2. If all three arguments (job-pattern, category, value) are provided:\n - Validate the category exists in the snapshot file\n - Skip the corresponding prompting steps\n - Use the provided values directly\n3. If some arguments are missing, prompt only for the missing ones\n4. If no arguments are provided, follow the full interactive workflow below\n\nYou will guide the user through the following steps (skipping steps where arguments were provided):\n\n1. **Prompt for a Job Pattern**: Ask the user to enter a pattern that identifies the CI job(s) they want to update. This can be either a full job name or a substring. This will be used to add pattern matching logic to the Go code.\n - Example full job name: `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`\n - Example substrings: `-hypershift-`, `-metal-ipi-`, `-fips-`\n - **Important**: Both full job names and substrings are acceptable. Accept whatever the user provides without asking for clarification.\n - Advise the user that more specific patterns avoid unintended matches (e.g., `-metal-ipi-ovn-ipv6-` instead of just `-metal-`)\n\n2. **Select Variant Category**: Extract variant categories programmatically and present as a numbered list:\n - Run: `grep -E \"^ [A-Z]\" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u`\n - This extracts all unique variant categories from the snapshot file\n - Present the list with numbers (1, 2, 3, etc.) and ask the user to select by number\n\n3. **Select New Value**: Based on the chosen category, extract possible values programmatically and present as a numbered list:\n - For most categories, extract values from the snapshot: `grep \"^ :\" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/\"//g' | sort -u`\n - Present the unique values as a numbered list and ask the user to select by number\n - For Release-related variants (Release, FromRelease, FromReleaseMajor, FromReleaseMinor, ReleaseMajor, ReleaseMinor), allow free-text input instead of showing a numbered list\n\n4. **Modify the Go Code**: Update `pkg/variantregistry/ocp.go` to add the pattern matching logic:\n - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.)\n - Add an entry to the pattern matching logic in that function with the pattern and new value\n - Follow the existing code style and pattern structure (see examples in the file)\n - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins.\n - More specific patterns come before more generic patterns\n - Example: In `setPlatform`, \"-rosa\" must come before \"-aws\" because ROSA jobs contain \"aws\"\n - Example: In `setOwner`, \"-perfscale\" must come before \"-qe\" because perfscale jobs may contain \"qe\"\n - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point\n - Check if the new pattern might overlap with existing patterns and ensure correct precedence\n\n5. **Preview Changes with Test**: Run the variant snapshot test to see what will change:\n - Execute: `go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 \"Summary of changes:\"`\n - Parse this output to extract the variant category changed, old/new values, affected jobs, and total count\n - Display the summary to the user\n\n6. **Apply Changes**: Execute `make update-variants` to regenerate `pkg/variantregistry/snapshot.yaml`\n\n7. **Verify Unintended Changes** (optional manual step):\n - Suggest the user review `git diff pkg/variantregistry/snapshot.yaml` to ensure only expected jobs changed\n\n8. **Offer to Commit**: Ask the user if they want to commit the changes. If yes, commit both the Go code and the regenerated snapshot.\n\n## Important Notes\n\n- The variant logic is defined in `pkg/variantregistry/ocp.go` in setter functions\n- Each variant category has its own setter function with a pattern matching list\n- The `make update-variants` command runs `./sippy variants snapshot --config ./config/openshift.yaml`\n- This regenerates `pkg/variantregistry/snapshot.yaml` based on the Go code logic\n- Always commit both the Go code changes AND the regenerated snapshot.yaml\n- Pattern matching is done with `strings.Contains(jobNameLower, pattern)`\n\n## Helper Commands\n\n### Extracting Variant Categories\n```bash\ngrep -E \"^ [A-Z]\" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u\n```\n\n### Extracting Values for a Specific Category\n```bash\ngrep \"^ :\" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/\"//g' | sort -u\n```\n\n### Previewing Changes\n```bash\ngo test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 \"Summary of changes:\"\n```\n\n### Finding Setter Functions\n```bash\ngrep -E \"^func set[A-Z]\" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort\n```\n\n### Pattern Ordering is CRITICAL\n- **The setter functions use early return - the FIRST matching pattern wins**\n- More specific patterns MUST appear before more generic patterns\n- Common examples to learn from:\n - `-rosa` before `-aws` (ROSA jobs contain \"aws\")\n - `-azure-aro-hcp` before `-azure` (ARO jobs contain \"azure\")\n - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain \"gcp\")\n - `-perfscale` before `-qe` (perfscale jobs may contain \"qe\")\n- Always verify the diff doesn't show unintended changes to other jobs" diff --git a/.opencode/commands/sippy-generate-release-views.md b/.opencode/commands/sippy-generate-release-views.md index 88e270fbb..4737cda7d 100644 --- a/.opencode/commands/sippy-generate-release-views.md +++ b/.opencode/commands/sippy-generate-release-views.md @@ -1,9 +1,15 @@ --- +argument-hint: +arguments: +- source-release +- target-release description: Generate new component readiness views for a new release --- # Generate Release Views +> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + This command generates new component readiness views for a new release by copying and updating existing views from a previous release. ## Arguments (all optional) @@ -36,7 +42,7 @@ If any arguments are not provided, you will prompt the user interactively. - **Base Release**: - If base = sample (same-release comparison), both become target - If base != sample (cross-release comparison), increment base by one minor version - - **IMPORTANT**: When base becomes source release, replace 'ga' with 'now' in relative_start and relative_end + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` 5. **Verify Output**: Show a diff of the changes made to views.yaml @@ -55,7 +61,7 @@ When copying a view from source release to target release: 3. **Base Release Update**: Depends on the original relationship - **Same-release views** (base = sample): Both become target - **Cross-release views** (base != sample): Base increments by one - - **CRITICAL**: When base becomes source release, replace 'ga' with 'now' in relative dates + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` ## Examples diff --git a/.opencode/commands/sippy-update-ga-release-views.md b/.opencode/commands/sippy-update-ga-release-views.md index 0a737a518..15b5aa6c4 100644 --- a/.opencode/commands/sippy-update-ga-release-views.md +++ b/.opencode/commands/sippy-update-ga-release-views.md @@ -1,4 +1,7 @@ --- +argument-hint: +arguments: +- release description: Update component readiness views when a release goes GA --- @@ -43,8 +46,6 @@ If the argument is not provided, you will prompt the user interactively. **F. Decrease pass_rate_required_new_tests**: - Set `pass_rate_required_new_tests` to `90` (from 95) - - **IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) - 4. **Verify Output**: Show a diff of the changes made to views.yaml 5. **Run Validation Test**: @@ -69,4 +70,6 @@ This command is part of the release lifecycle workflow: - Views where `sample_release.release` equals the GA release (sensitivity reductions) - Use the Edit tool for each change to preserve exact YAML formatting - Always verify the diff to ensure only expected changes were made -- This is typically run once when a release goes GA \ No newline at end of file +- This is typically run once when a release goes GA + +**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) \ No newline at end of file diff --git a/.opencode/commands/sippy-update-job-variant.md b/.opencode/commands/sippy-update-job-variant.md index f5e0ab057..0c5dad130 100644 --- a/.opencode/commands/sippy-update-job-variant.md +++ b/.opencode/commands/sippy-update-job-variant.md @@ -1,4 +1,9 @@ --- +argument-hint: +arguments: +- job-pattern +- category +- value description: Interactively update variants for a CI job --- @@ -49,8 +54,8 @@ You will guide the user through the following steps (skipping steps where argume - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.) - Add an entry to the pattern matching logic in that function with the pattern and new value - Follow the existing code style and pattern structure (see examples in the file) - - **CRITICAL**: Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. - - More specific patterns MUST come before more generic patterns + - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. + - More specific patterns come before more generic patterns - Example: In `setPlatform`, "-rosa" must come before "-aws" because ROSA jobs contain "aws" - Example: In `setOwner`, "-perfscale" must come before "-qe" because perfscale jobs may contain "qe" - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point @@ -77,16 +82,6 @@ You will guide the user through the following steps (skipping steps where argume - Always commit both the Go code changes AND the regenerated snapshot.yaml - Pattern matching is done with `strings.Contains(jobNameLower, pattern)` -### Pattern Ordering is CRITICAL -- **The setter functions use early return - the FIRST matching pattern wins** -- More specific patterns MUST appear before more generic patterns -- Common examples to learn from: - - `-rosa` before `-aws` (ROSA jobs contain "aws") - - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") - - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") - - `-perfscale` before `-qe` (perfscale jobs may contain "qe") -- Always verify the diff doesn't show unintended changes to other jobs - ## Helper Commands ### Extracting Variant Categories @@ -107,4 +102,14 @@ go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "S ### Finding Setter Functions ```bash grep -E "^func set[A-Z]" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort -``` \ No newline at end of file +``` + +### Pattern Ordering is CRITICAL +- **The setter functions use early return - the FIRST matching pattern wins** +- More specific patterns MUST appear before more generic patterns +- Common examples to learn from: + - `-rosa` before `-aws` (ROSA jobs contain "aws") + - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") + - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") + - `-perfscale` before `-qe` (perfscale jobs may contain "qe") +- Always verify the diff doesn't show unintended changes to other jobs \ No newline at end of file diff --git a/AGENTS.md b/AGENTS.md index 2a6db537b..eca67802a 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,7 +1,7 @@ # AGENTS.md - - + + ## Files matching `**` diff --git a/CLAUDE.md b/CLAUDE.md index 2d6a56143..5d6024173 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,7 +1,7 @@ # CLAUDE.md - - + + # Project Standards diff --git a/GEMINI.md b/GEMINI.md index 123ba5eb3..f933b9480 100644 --- a/GEMINI.md +++ b/GEMINI.md @@ -1,6 +1,6 @@ # GEMINI.md - - + + @./AGENTS.md diff --git a/Makefile b/Makefile index 0cb140d4a..ac4456878 100644 --- a/Makefile +++ b/Makefile @@ -62,8 +62,8 @@ clean: rm -rf sippy-ng/node_modules apm: - uvx --from apm-cli@0.11.0 apm install - uvx --from apm-cli@0.11.0 apm compile + uvx --from apm-cli@0.12.4 apm install + uvx --from apm-cli@0.12.4 apm compile verify-apm: apm @if ! git diff --quiet HEAD -- .claude .cursor .gemini .opencode AGENTS.md CLAUDE.md GEMINI.md sippy-ng/AGENTS.md sippy-ng/CLAUDE.md mcp/AGENTS.md mcp/CLAUDE.md; then \ diff --git a/apm.lock.yaml b/apm.lock.yaml index 0277363ae..39999d874 100644 --- a/apm.lock.yaml +++ b/apm.lock.yaml @@ -19,6 +19,16 @@ local_deployed_files: - .claude/rules/general.md - .claude/rules/mcp.md - .claude/rules/testing.md +- .cursor/commands/sippy-dev-app.md +- .cursor/commands/sippy-dev-frontend.md +- .cursor/commands/sippy-dev-migrate.md +- .cursor/commands/sippy-dev-regression-cache.md +- .cursor/commands/sippy-dev-serve.md +- .cursor/commands/sippy-dev-setup.md +- .cursor/commands/sippy-dev-tests.md +- .cursor/commands/sippy-generate-release-views.md +- .cursor/commands/sippy-update-ga-release-views.md +- .cursor/commands/sippy-update-job-variant.md - .cursor/rules/backend.mdc - .cursor/rules/dev-commands.mdc - .cursor/rules/frontend.mdc @@ -53,15 +63,25 @@ local_deployed_file_hashes: .claude/commands/sippy-dev-serve.md: sha256:89a89448d948c68304471f7d872e8cb3395b83895f5d0a051f57a07252f50c34 .claude/commands/sippy-dev-setup.md: sha256:276c708371bebcdbe8602df22ca482e59c2eab0bbc7ecacf1b49acd0a99d966f .claude/commands/sippy-dev-tests.md: sha256:26dfc22708d0e3bd4879640b4b9f090fc0b3fcaa21957ca0e4a52305bc9cb593 - .claude/commands/sippy-generate-release-views.md: sha256:e8a283e43f84777e6da34c10f1b18de2c41baa4525a7e40317bddd0c61b75553 - .claude/commands/sippy-update-ga-release-views.md: sha256:c7adb0f649455fa7c12c94454220fc87f182d49b820a2683ca733401cbfeb9b0 - .claude/commands/sippy-update-job-variant.md: sha256:ef00ec3a3b01556b33243d3e17ab1ace23879a8ef10dfd2e501a0fda2291fb97 + .claude/commands/sippy-generate-release-views.md: sha256:eb4c9eeeea2ab2a90e8a8839147d8a1a309ea6ce3dafd397c6d2485c93068a9a + .claude/commands/sippy-update-ga-release-views.md: sha256:4a5589bacc05127e427a2de4d34a8f13e05e297bdf6ebf7473c9e71f47a6b4f4 + .claude/commands/sippy-update-job-variant.md: sha256:f88742dddeec5024931959a8330fdce362ffdd9b8825e808830ac346605cbd16 .claude/rules/backend.md: sha256:c57f9ef479340d977f06266779cacc8cd0a67cf045a58d30757a0c494354081a .claude/rules/dev-commands.md: sha256:4508eaad3d835305b68106ed5b270ced97c93e4a42ee94d1bcac5ea7b056bc5d .claude/rules/frontend.md: sha256:ff22046c5b951769218bbdf36499e67c70896811b8ef161ca6d3729a3423997d .claude/rules/general.md: sha256:9238d053e2d6a1703728c2bb165de93658b47c3152dfac16169ff9db9c6f716c .claude/rules/mcp.md: sha256:73735078b3b1a8597b91b49821ba05cdb338144ea00c1eea9e9f4de38d0241a3 .claude/rules/testing.md: sha256:57834092f6732d17f8c1812d25290cfc1cfbbbeb6eae1561ba2240973c651866 + .cursor/commands/sippy-dev-app.md: sha256:44a111c7cbd34d2480658b39f9b01a18cb80e0f50b4a652cae4c255d123595a4 + .cursor/commands/sippy-dev-frontend.md: sha256:42eae4b3bc610c9fcb43533a6fed229a6d1c409d279f3d6f93672986ede62e3a + .cursor/commands/sippy-dev-migrate.md: sha256:5704945283027398bbe4a54eb4d97295059bd64a47e86e97a58665338ec62c8b + .cursor/commands/sippy-dev-regression-cache.md: sha256:4e9fc3ed63927c84c30554929768a3b0e760264925f55c9dbbdafabf2361bee2 + .cursor/commands/sippy-dev-serve.md: sha256:89a89448d948c68304471f7d872e8cb3395b83895f5d0a051f57a07252f50c34 + .cursor/commands/sippy-dev-setup.md: sha256:276c708371bebcdbe8602df22ca482e59c2eab0bbc7ecacf1b49acd0a99d966f + .cursor/commands/sippy-dev-tests.md: sha256:26dfc22708d0e3bd4879640b4b9f090fc0b3fcaa21957ca0e4a52305bc9cb593 + .cursor/commands/sippy-generate-release-views.md: sha256:eb4c9eeeea2ab2a90e8a8839147d8a1a309ea6ce3dafd397c6d2485c93068a9a + .cursor/commands/sippy-update-ga-release-views.md: sha256:4a5589bacc05127e427a2de4d34a8f13e05e297bdf6ebf7473c9e71f47a6b4f4 + .cursor/commands/sippy-update-job-variant.md: sha256:f88742dddeec5024931959a8330fdce362ffdd9b8825e808830ac346605cbd16 .cursor/rules/backend.mdc: sha256:fb466b896d76ea1730c23d6c3fc783adf2cd5502c1cbb36e5b3d30c01531e4c1 .cursor/rules/dev-commands.mdc: sha256:c69ca93db9b6c68f9aeb6567289dc5baef805520e8636a1e3e848793f67450e6 .cursor/rules/frontend.mdc: sha256:497f39372724f1ae127181fe3dac9ea9a95a51c532b68ccfee6080832cf9c556 @@ -75,9 +95,9 @@ local_deployed_file_hashes: .gemini/commands/sippy-dev-serve.toml: sha256:adff646a493861ca4bb5246fb32b6eb69dc77829d05b74b8e7c241cb08dff808 .gemini/commands/sippy-dev-setup.toml: sha256:bb56074029f5a73075f7d8b5e971ad2621d0517ea29a90bbb1e11f989bd6295c .gemini/commands/sippy-dev-tests.toml: sha256:0b5f406eac7adca8ee4db287973368b9dea048f89f0fdf86e3fc9730646c8d47 - .gemini/commands/sippy-generate-release-views.toml: sha256:4759f4547c05631d2e83a5859172421ea3d6ec794dd887756a90bbe0fd2732c1 - .gemini/commands/sippy-update-ga-release-views.toml: sha256:71a60dfe068bdc59645b8d0069c93c65f2df30c5172da3389df2a80d86410ae9 - .gemini/commands/sippy-update-job-variant.toml: sha256:71c9c7548a1a4b829e970d76504ef981ea05fecf8052cdb86859d96ad52cb2b2 + .gemini/commands/sippy-generate-release-views.toml: sha256:9173d7507f469eda21a19f7e5ec47bce0c6ce87a73c1f5c10594a89417332927 + .gemini/commands/sippy-update-ga-release-views.toml: sha256:662ac8d503d883cf6142c801b79e46616afb3d806e1d936e952d918b257ddf73 + .gemini/commands/sippy-update-job-variant.toml: sha256:3b044dfaddeafa1a6d375918d5860785f8d315b593c355bbb7293a87c50361b8 .opencode/commands/sippy-dev-app.md: sha256:44a111c7cbd34d2480658b39f9b01a18cb80e0f50b4a652cae4c255d123595a4 .opencode/commands/sippy-dev-frontend.md: sha256:42eae4b3bc610c9fcb43533a6fed229a6d1c409d279f3d6f93672986ede62e3a .opencode/commands/sippy-dev-migrate.md: sha256:5704945283027398bbe4a54eb4d97295059bd64a47e86e97a58665338ec62c8b @@ -85,6 +105,6 @@ local_deployed_file_hashes: .opencode/commands/sippy-dev-serve.md: sha256:89a89448d948c68304471f7d872e8cb3395b83895f5d0a051f57a07252f50c34 .opencode/commands/sippy-dev-setup.md: sha256:276c708371bebcdbe8602df22ca482e59c2eab0bbc7ecacf1b49acd0a99d966f .opencode/commands/sippy-dev-tests.md: sha256:26dfc22708d0e3bd4879640b4b9f090fc0b3fcaa21957ca0e4a52305bc9cb593 - .opencode/commands/sippy-generate-release-views.md: sha256:e8a283e43f84777e6da34c10f1b18de2c41baa4525a7e40317bddd0c61b75553 - .opencode/commands/sippy-update-ga-release-views.md: sha256:c7adb0f649455fa7c12c94454220fc87f182d49b820a2683ca733401cbfeb9b0 - .opencode/commands/sippy-update-job-variant.md: sha256:ef00ec3a3b01556b33243d3e17ab1ace23879a8ef10dfd2e501a0fda2291fb97 + .opencode/commands/sippy-generate-release-views.md: sha256:eb4c9eeeea2ab2a90e8a8839147d8a1a309ea6ce3dafd397c6d2485c93068a9a + .opencode/commands/sippy-update-ga-release-views.md: sha256:4a5589bacc05127e427a2de4d34a8f13e05e297bdf6ebf7473c9e71f47a6b4f4 + .opencode/commands/sippy-update-job-variant.md: sha256:f88742dddeec5024931959a8330fdce362ffdd9b8825e808830ac346605cbd16 diff --git a/apm.yml b/apm.yml index 66d9d274f..0fefeac4d 100644 --- a/apm.yml +++ b/apm.yml @@ -1,9 +1,15 @@ name: sippy version: 1.0.0 description: CI analysis and release health monitoring for OpenShift -target: [claude, cursor, gemini, opencode] +targets: + - claude + - cursor + - gemini + - opencode -dependencies: {} +dependencies: # External dependencies can be pulled from GitHub, e.g.: # apm: # - openshift-eng/ai-helpers/plugins/bigquery + apm: [] + mcp: [] diff --git a/mcp/AGENTS.md b/mcp/AGENTS.md index 6b1ea53f2..dbabdd889 100644 --- a/mcp/AGENTS.md +++ b/mcp/AGENTS.md @@ -1,7 +1,7 @@ # AGENTS.md - - + + ## Files matching `mcp/**` diff --git a/mcp/CLAUDE.md b/mcp/CLAUDE.md index 11b6b2fa2..4ca090caa 100644 --- a/mcp/CLAUDE.md +++ b/mcp/CLAUDE.md @@ -1,7 +1,7 @@ # CLAUDE.md - - + + # Project Standards diff --git a/sippy-ng/AGENTS.md b/sippy-ng/AGENTS.md index 8cc348b84..e715c721a 100644 --- a/sippy-ng/AGENTS.md +++ b/sippy-ng/AGENTS.md @@ -1,7 +1,7 @@ # AGENTS.md - - + + ## Files matching `sippy-ng/**` diff --git a/sippy-ng/CLAUDE.md b/sippy-ng/CLAUDE.md index 97779f3d4..3f9a23ec1 100644 --- a/sippy-ng/CLAUDE.md +++ b/sippy-ng/CLAUDE.md @@ -1,7 +1,7 @@ # CLAUDE.md - - + + # Project Standards