ci: add RHCOS version confirmation from job artifacts

.claude-plugin/marketplace.json

@@ -49,7 +49,7 @@
       "name": "ci",
       "source": "./plugins/ci",
       "description": "A plugin to work with OpenShift CI and analyze Prow job results",
-      "version": "0.0.49",
+      "version": "0.0.50",
       "category": "ci",
       "keywords": [
         "prow",

docs/index.html

@@ -487,7 +487,7 @@ <h1>ai-helpers</h1>
     {
       "name": "ci",
       "description": "Tools for working with OpenShift CI and analyzing Prow job results",
-      "version": "0.0.49",
+      "version": "0.0.50",
       "has_readme": true,
       "commands": [
         {

plugins/ci/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "ci",
   "description": "Tools for working with OpenShift CI and analyzing Prow job results",
-  "version": "0.0.49",
+  "version": "0.0.50",
   "author": {
     "name": "github.com/openshift-eng"
   }

plugins/ci/references/jobs.md

@@ -45,6 +45,43 @@ Job names may contain fragments that indicate which RHCOS variant the cluster us
 
 For upgrade jobs, use the **install-time** OCP version (see "Upgrade Jobs" above), not the payload/target version. This matters for major upgrades: a major upgrade job in a 5.x payload installs OCP 4.x, so its RHCOS default follows OCP 4.x rules.
 
+### Confirming RHCOS version from artifacts
+
+The job-name heuristic infers the RHCOS version but can't confirm it. To verify the actual RHCOS variant a cluster ran, inspect `.status.nodeInfo.osImage` on Node resources in the job's artifacts.
+
+**Preferred source — `nodes.json` in gather-extra:**
+
+```
+artifacts/{target}/gather-extra/artifacts/nodes.json
+```
+
+This is a JSON file containing Node resources. Use `prow-job-artifact-search` to find and fetch it:
+
+```bash
+# Find nodes.json
+prow_job_artifact_search.py <url> search "**/nodes.json" artifacts
+
+# Fetch it
+prow_job_artifact_search.py <url> fetch artifacts/{target}/gather-extra/artifacts/nodes.json
+```
+
+**Fallback — must-gather node YAMLs:**
+
+```
+cluster-scoped-resources/core/nodes/*.yaml
+```
+
+Each file is a single Node resource with the same `.status.nodeInfo.osImage` field.
+
+**Interpreting `osImage` values:**
+
+The version number after "Red Hat Enterprise Linux CoreOS" indicates the RHEL base:
+
+- RHCOS 9: version starts with `9.` — e.g., `Red Hat Enterprise Linux CoreOS 9.8.20260613-0 (Plow)`
+- RHCOS 10: version starts with `10.` — e.g., `Red Hat Enterprise Linux CoreOS 10.2.20260521-0 (Coughlan)`
+
+A cluster with mixed `osImage` values across nodes is heterogeneous (RHCOS 9 + 10).
+
 ### Analysis implications
 
 Variant isolation (a failure appearing only on one RHCOS variant) is diagnostic context that narrows the root cause to OS-specific changes (kernel, systemd, SELinux, package differences between RHEL 9 and RHEL 10).

plugins/ci/skills/prow-job-analyze-install-failure/SKILL.md

@@ -135,6 +135,22 @@ Use the `fetch-prowjob-json` skill to fetch the prowjob.json for this job. See `
    - Capture the target value (e.g., `e2e-aws-ovn-techpreview`)
    - Store for constructing artifact paths
 
+### Step 3b: Confirm RHCOS Version
+
+Use `prow-job-artifact-search` to look for `nodes.json` in gather-extra:
+
+```
+artifacts/{target}/gather-extra/artifacts/nodes.json
+```
+
+If found, parse the JSON and extract `.status.nodeInfo.osImage` from each Node item — the version number after "Red Hat Enterprise Linux CoreOS" indicates the RHEL base:
+- Version starts with `9.` → RHCOS 9 (e.g., `Red Hat Enterprise Linux CoreOS 9.8.20260613-0 (Plow)`)
+- Version starts with `10.` → RHCOS 10 (e.g., `Red Hat Enterprise Linux CoreOS 10.2.20260521-0 (Coughlan)`)
+
+Report the confirmed RHCOS version(s) in the analysis output. If nodes show mixed osImage values, the cluster is heterogeneous (RHCOS 9 + 10).
+
+This file may not exist for early install failures (bootstrap, infrastructure) where the cluster never progressed far enough to have nodes or run gather-extra. If unavailable, skip — this step is informational, not blocking.
+
 ### Step 4: Download JUnit XML to Identify Failure Stage
 
 **Note on install-status.txt**: You may see an `install-status.txt` file in the artifacts. This file contains only the installer's exit code (a single number). The junit_install.xml file translates this exit code into a human-readable failure mode, so always prefer junit_install.xml for determining the failure stage.

plugins/ci/skills/prow-job-analyze-test-failure/SKILL.md

@@ -92,6 +92,20 @@ Use the `fetch-prowjob-json` skill to fetch the prowjob.json for this job. See `
    - Note: on PR jobs `{target}` and `{JOB_NAME}` often differ. All artifact-path lookups
      (JUnit XML, step logs, step artifacts) must use `{JOB_NAME}`, not `{target}`
 
+### Step 3b: Confirm RHCOS Version
+
+Use `prow-job-artifact-search` to fetch `nodes.json` from the gather-extra artifacts:
+
+```
+artifacts/{target}/gather-extra/artifacts/nodes.json
+```
+
+Parse the JSON and extract `.status.nodeInfo.osImage` from each Node item. This confirms the actual RHCOS variant the cluster ran — the version number after "Red Hat Enterprise Linux CoreOS" indicates the RHEL base:
+- Version starts with `9.` → RHCOS 9 (e.g., `Red Hat Enterprise Linux CoreOS 9.8.20260613-0 (Plow)`)
+- Version starts with `10.` → RHCOS 10 (e.g., `Red Hat Enterprise Linux CoreOS 10.2.20260521-0 (Coughlan)`)
+
+If nodes show mixed osImage values, the cluster is heterogeneous (RHCOS 9 + 10). Report the confirmed RHCOS version(s) in the analysis output. If `nodes.json` is unavailable (e.g., gather-extra didn't run), skip this step — it's informational, not blocking.
+
 ### Step 4: Analyze Test Failure
 
 ### Step 4.0: Detect Aggregated Jobs