feat(conformance): add version for conformance test report.

[zetxqx]

1. add GatewayAPIInferenceExtensionVersion to the conformance report.
2. add a consts following the style in gateway api. currently only conformance tests is using it, I'll have a following PR to follow the gateway-api pattern to generate CRD and add annotations.
3. update the reports.md a little bit.

Example report now(the first line have the GatewayAPIInferenceExtensionVersion):

GatewayAPIInferenceExtensionVersion: v0.5.0
apiVersion: gateway.networking.k8s.io/v1
date: "2025-07-09T21:02:57Z"
gatewayAPIChannel: UNDEFINED
gatewayAPIVersion: UNDEFINED
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.

[netlify]

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

Name	Link
🔨 Latest commit	f43af26
🔍 Latest deploy log	https://app.netlify.com/projects/gateway-api-inference-extension/deploys/68755bd216164e00089679a2
😎 Deploy Preview	https://deploy-preview-1133--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

[robscott]

Thanks @zetxqx!

[robscott]

Thanks @zetxqx!

/lgtm
/ok-to-test

[robscott]

Thanks @zetxqx!

/lgtm

[nirrozenbaum]

shared offline with @zetxqx my concern about the name selection consts and it's location under pkg which may become a place where everybody put their non related consts, like a centralized place for putting all constants of the repo which I'm generally against.

we agreed to create a version/version.go at the root level to specify versioning related consts (package version).
for example like this project:
https://github.com/kubernetes/kops/blob/master/kops-version.go

[nirrozenbaum]

not related to this PR, but using version.go will also allow us to define in this file CommitSHA and BuildRef vars which are currently located under /epp/pkg/metrics/metrics.go (I don't see how is it related to metrics.go).

gateway-api-inference-extension/pkg/epp/metrics/metrics.go

Lines 39 to 45 in 48966b8

	var (
	// The git hash of the latest commit in the build.
	CommitSHA string
	// The build ref from the _PULL_BASE_REF from cloud build trigger.
	BuildRef string
	)

I will push it in a follow up PR. (cc @kfswain)

[zetxqx]

Good point! thanks @nirrozenbaum , renamed to version/version.go. Could you take another look?

cc: @robscott

[kfswain]

@JeffLuoo wrote this, I believe, to emit the commitSHA to help give context to any logs emitted (so when debugging, you can look at the specific SHA & know what the codebase looked like at that point in time). I think same with the pull base. I believe that is the fork the build is based on. Jeff to confirm however.

[JeffLuoo]

I placed the var in metrics.go for adding the metadata metric related to the IG https://github.com/kubernetes-sigs/gateway-api-inference-extension/blob/main/cmd/epp/runner/runner.go#L245. The metric tells you the build hash and version (usually tag) of the image.

Those two variables are passed in from the Dockerfile in go build here: https://github.com/kubernetes-sigs/gateway-api-inference-extension/blob/main/Dockerfile#L25 where the variables are passed in from:

gateway-api-inference-extension/cloudbuild.yaml

Lines 12 to 15 in c46a7e7

	- GIT_TAG=$_GIT_TAG
	- EXTRA_TAG=$_PULL_BASE_REF
	- DOCKER_BUILDX_CMD=/buildx-entrypoint
	- GIT_COMMIT_SHA=$_PULL_BASE_SHA

PULL_BASE_SHA is a keyword that cloudbuild job will use to set the environment variable, check https://docs.prow.k8s.io/docs/jobs/ for environment variables. I used PULL_BASE_REF and PULL_BASE_SHA.

When you add the change, can you make sure the metric will still have the hash and build tag?

[nirrozenbaum]

@JeffLuoo sure!
thanks for the detailed response 👍

[nirrozenbaum]

/lgtm
/approve

Thanks!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nirrozenbaum, 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 [nirrozenbaum]

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