feat(conformance): Use CRD annotation to populate the ConformanceReport GatewayAPIInferenceExtensionVersion

[zetxqx]

Currently, the conformance report is using hard-coded variable BundleVersion in version.go. This PR get the version from annotation BundleVersionAnnotation of installed CRDs.

Tested locally, the following is an example generated report, I installed v0.5.0 CRDs.

GatewayAPIInferenceExtensionVersion: v0.5.0
apiVersion: gateway.networking.k8s.io/v1
date: "2025-07-22T05:30:18Z"
gatewayAPIChannel: standard
gatewayAPIVersion: v1.2.1
implementation:
  contact:
  - gke-gateway-dev@google.com
  organization: GKE
  project: gke-gateway
  url: https://cloud.google.com/kubernetes-engine/docs/concepts/gateway-api
  version: TBD
kind: ConformanceReport
mode: default
profiles:
- core:
    result: success
    statistics:
      Failed: 0
      Passed: 9
      Skipped: 0
  name: Gateway
  summary: Core tests succeeded.

A follow up PR is to change BundleVersion from v1.0.0-dev to main-dev.

[netlify]

✅ Deploy Preview for gateway-api-inference-extension ready!

Name	Link
🔨 Latest commit	4e3a39d
🔍 Latest deploy log	https://app.netlify.com/projects/gateway-api-inference-extension/deploys/68b0a5736bd83e0008fa5b30
😎 Deploy Preview	https://deploy-preview-1214--gateway-api-inference-extension.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

Hi @zetxqx. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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 kubernetes-sigs/prow repository.

[zetxqx]

/assign @robscott
/assign @nirrozenbaum

[ahg-g]

/ok-to-test

[kfswain]

/approve

This looks good to me. Will let one of the manual assignees give final stamp

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kfswain, zetxqx

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 [kfswain]

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

[robscott]

Thanks @zetxqx!

/lgtm

[zetxqx]

Thanks! @kfswain

/hold

Looks like the manifest in the latest release(https://github.com/kubernetes-sigs/gateway-api-inference-extension/releases/tag/v0.5.1) does not have the annotation yet. This should be submitted after a new release.

[kfswain]

Sorry, what annotation is needed? We probably wont have a release for a bit, so trying to understand what's preventing this from merging

[zetxqx]

Sorry, what annotation is needed? We probably wont have a release for a bit, so trying to understand what's preventing this from merging

@kfswain the change here reads the annotation from inferencePool's CRD to populate the ConformanceReport GatewayAPIInferenceExtensionVersion. However, currently in the v0.5.0 release we don't have the annotation attached. It's because my change #1134 is not included in the released manfest.yaml. Then when other's generating the report they may get an early returned error because of:

if inferenceVersion == "" {
      return "", errors.New("no gateway api inference extension CRDs with the proper annotations found in the cluster")
}

[danehans]

Holding until v1.0 is cut, which will include the "inference.networking.k8s.io/bundle-version" CRD annotation.

[nirrozenbaum]

I noticed the use of context in conformance is not aligned with best practices.
I was hoping to see context created one time in "main" (e.g., in the entry point), and then ctx is propagated in the function calls (usually as first arg).
I've never ran the conformance test suite myself, but if it's a long running process (more than few minutes), it may make sense to use context with signal handling (listening to SIGTERM, SIGKILL).
see example in our main file where we use SetupSignalHandler():

gateway-api-inference-extension/cmd/epp/main.go

Line 31 in 6491db2

if err := runner.NewRunner().Run(ctrl.SetupSignalHandler()); err != nil {

[zetxqx]

Really good call! I've replaced it by creating a context.Background() at the start of the test run and propagating it down. The conformance tests is executed by go test. Each test function serves as its own entry point. The overall process termination is managed by the go test --timeout flag, so setting up a custom signal handler here isn't necessary as it would be in a long-running service.

Ref:

gateway-api-inference-extension/conformance/conformance_test.go

Line 26 in 6491db2

func TestConformance(t *testing.T) {

is the entryPoint for conformance tests which is run by go test

[robscott]

Holding until v1.0 is cut, which will include the "inference.networking.k8s.io/bundle-version" CRD annotation.

@danehans any concerns with merging this now that we have this annotation in place for CRDs?

[danehans]

/lgtm

[robscott]

/hold cancel