envoyproxy Envoy Gateway PR Review Skill
Inputs
- GitHub PR URL (e.g. review PR: https://github.com/envoyproxy/gateway/pull/8237), or
- A local diff between commits (e.g. review change: git diff 4927877a HEAD)
Output
- Lead with findings ordered by severity.
- Include exact file and line references.
- Separate required fixes from optional follow-ups.
- If there are no findings, say that clearly and mention residual test or release-note risk.
Review
- Check API changes, implementation changes, feature coverage, and release notes as applicable.
- Keep findings concise and actionable, with file references when possible.
Checklist
API changes
- Make sure changes under
api/align with https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md - Make sure changes under
api/are consistent with existing API patterns in the Gateway API project: https://github.com/kubernetes-sigs/gateway-api/tree/main/apis - Make sure changes under
api/are consistent with existing API patterns in this project. - Try to reuse existing types.
- Keep naming consistent with this project.
- Try to add kubebuilder and CEL validations to catch errors.
- Make sure API validations are tested in
/test/cel-validation. - Check backward compatibility for API shape, CRD schema, defaults, versioned structs, and upgrade behavior.
- If a PR mixes API and implementation changes, say whether it should be split into separate PRs.
Implementation changes
- For changes under
internal/gatewayapi, check that user-visible errors are surfaced in status. - For changes under
internal/gatewayapi, check that status conditions follow the conventions in the Gateway API spec: https://gateway-api.sigs.k8s.io/geps/gep-1364/index.html - For changes under
internal/gatewayapi, check thatinternal/gatewayapi/testdatahas coverage. - For changes under
internal/xds/translator, check thatinternal/xds/translator/testdatahas coverage.
Feature coverage
- For new user-facing features, check that
test/e2ehas coverage. - For bug fixes, check that
test/e2ehas coverage if the bug is in user-facing code or has user-facing impact.
Release notes
Release notes should be added as a new fragment file under release-notes/current/<section>/<pr-number>-<slug>.md (see release-notes/current/README.md) for any of the following changes. One change per file; the section directory determines the category.
- Bug fixes should be noted as "bug fix" (
bug_fixes/) and include a brief description of the issue and the fix. - New features should be noted as "new feature" and include a brief description of the feature.
- Any breaking changes should be noted as "breaking change" and include a clear description of the change and its impact on users.
- Any change to generated Envoy config (xDS) that moves, removes, or modifies existing config content would break EnvoyPatchPolicies and Extension Servers, so it should be noted as a breaking change. Additions to generated xDS config do not need to be called out.
- Existing API changes should be noted.
- Existing behavior changes should be noted.