fix(crd): correct EnvoyPatchPolicy printer columns

[Aditya7880900936]

What type of PR is this?

fix(crd): correct EnvoyPatchPolicy printer columns

What this PR does / why we need it:

This PR fixes the additionalPrinterColumns configuration for the
EnvoyPatchPolicy CRD.

Previously, the STATUS column was empty because the printer column
referenced a non-existent field under .status.conditions.
EnvoyPatchPolicy follows Gateway API conventions and stores conditions
under .status.ancestors[].conditions.

This change updates the printer columns to reference condition status
under .status.ancestors[].conditions, so
kubectl get envoypatchpolicies correctly shows Accepted and Programmed
states.

Which issue(s) this PR fixes:

Fixes #7745

Release Notes: No

[chaima-belhedi]

Thanx for taking care of this @Aditya7880900936

[Aditya7880900936]

Thanks a lot for the review and approval! Appreciate your time and guidance @chaima-belhedi

[arkodg]

how did you fix this without updating any markers

[arkodg]

you need to edit https://github.com/envoyproxy/gateway/blob/main/api/v1alpha1/envoypatchpolicy_types.go

[Aditya7880900936]

Thanks for the pointer!
I’ve updated the kubebuilder printcolumn annotations in envoypatchpolicy_types.go to reference status.ancestors[].conditions per Gateway API conventions and regenerated the CRDs.
Please let me know if anything else needs adjustment.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.61%. Comparing base (3ddf193) to head (c05f71d).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7776      +/-   ##
==========================================
- Coverage   72.64%   72.61%   -0.04%     
==========================================
  Files         235      235              
  Lines       34873    34873              
==========================================
- Hits        25334    25323      -11     
- Misses       7736     7744       +8     
- Partials     1803     1806       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zirain]

please run make -k gen-check locally, and commit the changes.

[Aditya7880900936]

I’ve run make -k gen-check locally and committed the updated helm test outputs.
Thanks!

[zirain]

why we only check the first ancestors?

[zirain]

is it possible to check any or all?

[Aditya7880900936]

status.ancestors can contain multiple entries, but kubectl printer columns need to resolve to a single scalar value and don’t support aggregation across arrays. Because of that, checking “any” or “all” ancestors isn’t supported in printer columns today.

Using ancestors[0] follows the existing Gateway API convention to surface the primary attachment point, and is consistent with how other policy CRDs expose status via printer columns.

Happy to adjust if there’s a preferred convention here.

[zirain]

what would happen if we use ancestors[*] here?

[Aditya7880900936]

If we use ancestors[*], the JSONPath evaluation would return a list of values rather than a single scalar (e.g. ["True", "False"] when multiple ancestors exist).

Kubectl printer columns don’t support aggregation or reduction over arrays, so returning a list can lead to unstable or non-deterministic output (empty values, joined lists, or differing behavior across kubectl versions).

That’s why most CRDs constrain printer columns to a single, deterministic value. Using ancestors[0] follows the existing Gateway API convention to surface the primary attachment point and keeps the printer column output stable and predictable.

For full multi-ancestor status, users can still inspect .status.ancestors directly via kubectl get -o yaml.

[zirain]

it's fine to me use ancestors[0], it's should be accepted for all or none.

@envoyproxy/gateway-maintainers PTAL

[Aditya7880900936]

Thanks for confirming! Happy to keep it consistent with ancestors[0] for both.

[arkodg]

yeah this is fine imo, order is unlikely to change

[arkodg]

does this work properly even when no status is set ? (when extensionApis.enableEnvoyPatchPolicy: false)

[Aditya7880900936]

Good question — yes, this should behave fine.

When extensionApis.enableEnvoyPatchPolicy is false, the controller doesn’t populate .status, so the JSONPath won’t resolve. In that case, kubectl printer columns simply render an empty value rather than erroring.

This is consistent with other Gateway API resources where status may be absent or delayed, and matches existing printer column behavior across CRDs.

Users can still inspect the full object via kubectl get -o yaml if needed.

[Aditya7880900936]

The remaining CI failures are from coverage-test.
This PR only updates CRD annotations and regenerated manifests, with no executable Go logic changes, so no additional coverage is produced.

Please let me know if you’d prefer:

skipping/overriding coverage for this PR, or

any specific test adjustments you’d like me to make.

[Aditya7880900936]

Friendly ping — happy to help unblock if anything else is needed.

[Aditya7880900936]

Thanks for the reviews and approvals!
The remaining CI failures are coverage-related and expected for this CRD-only change.
Happy to let maintainers decide the best way to proceed.

[Aditya7880900936]

Hi @zirain ,

The PR has approvals now. The only remaining CI failures are coverage tests, which appear expected for this CRD-only change.

Please let me know if you’re okay to merge as-is, or if you’d like me to make any changes before merge.

[Aditya7880900936]

Thanks everyone for the reviews and help!

[zirain]

/retest

[Aditya7880900936]

Friendly ping @zirain — whenever you’re back online, please take a look.
Happy to help if anything else is needed. Thanks!

[Aditya7880900936]

Hi @zirain ,
I checked the failing e2e jobs.

They fail in ZoneAwareRouting / BackendTrafficPolicy tests, which don’t appear related to this PR (CRD printer column metadata only).
The failure happens late in the suite and looks consistent with known e2e flakiness.

I’ve updated the branch to latest main.
Happy to re-run CI or dig further if needed.