TRT-2350: Include additional OTE metadata in JUnit results

[stbenjam]

This allows us to add additional important information into the JUnit BigQuery table for use in Component Readness, or AI tools for analysis (e.g. correlating test failures with intervals).

[openshift-ci-robot]

@stbenjam: This pull request references TRT-2350 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set.

In response to this:

This allows us to add additional important information into the JUnit BigQuery table for use in Component Readness, or AI tools for analysis (e.g. correlating test failures with intervals).

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[stbenjam]

/test e2e-aws-ovn

[neisw]

We updated TRT-2350 to also include test_repo and test_path attributes instead of doing it separately via autodl as originally requested in TRT-2326, is that something that can be added in this PR or needs to be done later?

[stbenjam]

/test e2e-aws-ovn

[stbenjam]

@neisw Updated to include additional info:

<testcase
  name="[Jira:config-operator][sig-api-machinery] sanity test should always pass [Suite:openshift/cluster-config-operator/conformance/parallel]"
  time="0"
  start-time="2025-11-12T20:06:48Z"
  end-time="2025-11-12T20:06:48Z"
  lifecycle="blocking"
  source-image="cluster-config-operator"
  source-binary="cluster-config-operator-tests-ext"
  source-commit="347bebcc1"
/>

[neisw]

Ok so the commit isn't specific to the the test so it won't help with knowing where the code for the test lives.

You had mentioned that the code path in ginkgo was somewhat nondeterministic I believe. Are we saying that for TRT-2326 we won't be able to do better than get them to the repo and the commit of that repo we are testing against?

I'm also wondering if we have a good way to translate source-image="hyperkube" to openshift/kubernetes?

I'm guessing not here but we would most likely do that in sippy for something like TRT-2326

<testcase 
name="[sig-api-machinery] FieldValidation should detect unknown metadata fields in both the root and embedded object of a CR [Conformance]" 
time="4.4" 
start-time="2025-11-13T17:00:11Z" 
end-time="2025-11-13T17:00:16Z" 
lifecycle="blocking" 
source-image="hyperkube" 
source-binary="k8s-tests-ext" 
source-commit="891f5bb0306166d5625b89fc8dc86bbc8c85f549"/>

[stbenjam]

• A commit SHA just tells tells you the level of the binary. There is no single commit attached to a test. You would never have any idea if some deep dependency of a test was touched in any particular commit. We just report the most recent sha of the repo when the binary was built

• I get the value of knowing a test’s source but Ginkgo’s codeLocations isn’t something I want to depend on yet. Our Ginkgo fork complicates things (we hack this codeLocations together). The list of locations is huge (some tests report 50 locations) and ambiguous without parsing the golang AST, and the format even changes depending on the build.

• source-repo is present in the JUnit XML, but not configured in most of the binaries. We need to do something like: UPSTREAM: <carry>: OTE extension should store repo source kubernetes#2516

But knowing the image name is enough to find it from the release payload:

$ oc adm release info registry.ci.openshift.org/ocp/release:4.21.0-0.nightly-2025-11-14-050926 -o json | jq '.references.spec.tags[] | select(.name == "hyperkube")'
{
  "name": "hyperkube",
  "annotations": {
    "io.openshift.build.commit.id": "891f5bb0306166d5625b89fc8dc86bbc8c85f549",
    "io.openshift.build.commit.ref": "",
    "io.openshift.build.source-location": "https://github.com/openshift/kubernetes",
    "io.openshift.build.version-display-names": "",
    "io.openshift.build.versions": "kubernetes=1.34.1"
  },
  "from": {
    "kind": "DockerImage",
    "name": "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:e31da3a2f57b7e72cfd0d089faa56a1cef3c11a227bf1ffac8ab078fea0bac41"
  },
  "generation": null,
  "importPolicy": {},
  "referencePolicy": {
    "type": ""
  }
}

[neisw]

/lgtm

It is getting us more data than we have now. Any gaps like the test location we can continue to evaluate.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: neisw, stbenjam

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [neisw,stbenjam]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[stbenjam]

/verified by presubmits

[openshift-ci-robot]

@stbenjam: This PR has been marked as verified by presubmits.

In response to this:

/verified by presubmits

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

Scheduling required tests:
/test e2e-aws-csi
/test e2e-aws-ovn-fips
/test e2e-aws-ovn-microshift
/test e2e-aws-ovn-microshift-serial
/test e2e-aws-ovn-serial-1of2
/test e2e-aws-ovn-serial-2of2
/test e2e-gcp-csi
/test e2e-gcp-ovn
/test e2e-gcp-ovn-upgrade
/test e2e-metal-ipi-ovn-ipv6
/test e2e-vsphere-ovn
/test e2e-vsphere-ovn-upi