Consolidate envoy gateway into calico#12757
Conversation
MichalFupso
added
docs-not-required
There was a problem hiding this comment.
Pull request overview
This PR makes Calico the single source of truth for the upstream Envoy Gateway version and the Helm-rendered manifest bundle that tigera/operator consumes, reducing the chance of silent drift between image/CVE patching and the operator-applied resources.
Changes:
- Add a
gen-gateway-api-resourcesmake target to rendergateway_api_resources.yamlfrom the pinnedENVOY_GATEWAY_VERSIONusing the upstreamenvoyproxy/gateway-helmchart. - Update Renovate to bump
ENVOY_GATEWAY_VERSION(patch updates only) and regenerate the rendered resources automatically after upgrades. - Adjust Semaphore change detection to avoid running the Envoy Gateway pipeline when only the generated
gateway_api_resources.yamlchanges.
Reviewed changes
Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
third_party/envoy-gateway/Makefile |
Adds a Helm templating target to regenerate the operator-consumed manifest bundle from the pinned Envoy Gateway version. |
renovate.json |
Adds a regex manager/rules to bump Envoy Gateway and run the regeneration target post-upgrade. |
.semaphore/semaphore.yml.d/blocks/20-envoy-gateway.yml |
Excludes the generated manifest from triggering the Envoy Gateway CI block. |
.semaphore/semaphore.yml |
Regenerates the main Semaphore pipeline with the same exclusion. |
.semaphore/semaphore-scheduled-builds.yml |
Applies the same exclusion to the scheduled-build pipeline. |
nelljerram
left a comment
nelljerram
left a comment
There was a problem hiding this comment.
I don't fully understand what the renovate changes are doing - is there e.g. a show and tell I can look at for that? But this looks like a nice change to me. One detailed query.
| - name: Envoy Gateway | ||
| run: | ||
| when: "${FORCE_RUN} or change_in(['/metadata.mk', '/lib.Makefile', '/third_party/envoy-gateway'], {pipeline_file: 'ignore', exclude: ['/**/.gitignore', '/**/README.md', '/**/LICENSE']})" | ||
| when: "${FORCE_RUN} or change_in(['/metadata.mk', '/lib.Makefile', '/third_party/envoy-gateway'], {pipeline_file: 'ignore', exclude: ['/**/.gitignore', '/**/README.md', '/**/LICENSE', '/third_party/envoy-gateway/gateway_api_resources.yaml']})" |
There was a problem hiding this comment.
Why this addition? I wouldn't expect the image building to depend on the YAMLs.
There was a problem hiding this comment.
It's part of the ignore config, so if there is a change in the yaml and nothing else we won't run the build.
|
|
||
| # For updating this version please see | ||
| # https://github.com/tigera/operator/blob/master/docs/common_tasks.md#updating-the-bundled-version-of-envoy-gateway | ||
| ENVOY_GATEWAY_VERSION=v1.7.2 |
There was a problem hiding this comment.
I know it's not part of your changes but reading your operator change, it seems to depend on having this strict format. if this changes format, renovate will silently fail. maybe adding commentary here helps? Idk what a better way would be
| # NB: keep literal `KEY=value` form (no spaces, no `?=`); Renovate regex + operator's | |
| # update-envoy-gateway-resources both parse this line. | |
| ENVOY_GATEWAY_VERSION=v1.7.2 |
| { | ||
| "description": "Regenerate envoy-gateway helm-rendered resources after version bump", | ||
| "matchPackageNames": ["envoyproxy/gateway"], | ||
| "postUpgradeTasks": { |
There was a problem hiding this comment.
Two flags on the new postUpgradeTasks:
-
Bot-side allowlist.
postUpgradeTasks.commandsis not honoured by Renovate unless the bot is allowed to execute it. There's precedent for that in this repo (themake gen-deps-filestask at line 103 already works), so it's likely fine, but some Mend setups allowlist per-command-prefix rather than blanket — worth a quick confirmation with whoever owns the Renovate config thatmake -C third_party/envoy-gateway gen-gateway-api-resourcesis permitted. If it isn't, Renovate will happily open the version-bump PR with the rendered YAML untouched, and the manifest will silently drift from the pin. -
Missing
matchBaseBranches. The existinggen-deps-filesrule at lines 100–107 is scoped to["master", "release-v3.31", "release-v3.32"]. The new envoy-gateway rules (108–127) have no such filter, so Renovate will try to bump envoy-gateway on every branch it scans, including older release branches that should be frozen. Suggest mirroring the samematchBaseBrancheslist on the envoy-gateway rules.
There was a problem hiding this comment.
For 2. I think we don't need it, 100 - 107 was added because we ran renovate on release 3.30 that did not contain the deps files, but renovate is only allowed to run on 3.31, 3.32 and master. Line 6. We can now remove the scope for make gen deps
| "description": "envoy-gateway: only patch updates allowed (block minor/major/digest)", | ||
| "matchPackageNames": ["envoyproxy/gateway"], | ||
| "matchUpdateTypes": ["minor", "major", "digest"], | ||
| "enabled": false |
There was a problem hiding this comment.
The PR body already documents this as a known limitation, but it's worth pinning the follow-up here so it doesn't get lost: when envoy-gateway eventually moves to a new minor (v1.8.0+), whoever does the bump has to manually update the matching versions in third_party/envoy-proxy/Makefile and third_party/envoy-ratelimit/Makefile per the compatibility matrix — Renovate won't help. Could you file a follow-up issue for automating that derivation and link it from a description field on this rule (or a comment immediately above)? Otherwise the next minor bump in ~6 months will rediscover this gap from scratch.
CI triage — CalicoRecommendation: Could not retrieve failure details for this run. Workflow header below: Workflow 86a1eaf5-bea6-4bcc-9b03-a7c45dd6e03averdict: failed Failed: E2E tests: Gateway API Conformance / Gateway API: Conformance Testsworkflow_id: 86a1eaf5-bea6-4bcc-9b03-a7c45dd6e03a |
This PR makes calico the single source of truth for the upstream Envoy Gateway version and the helm-rendered manifest bundle that tigera/operator consumes.
Today, ENVOY_GATEWAY_VERSION is pinned in both third_party/envoy-gateway/Makefile (drives source vendoring + CVE patches + image build) and tigera/operator's Makefile (drives helm template → pkg/render/gatewayapi/gateway_api_resources.yaml), and the two can drift silently.
This PR adds a gen-gateway-api-resources make target that runs helm template oci://docker.io/envoyproxy/gateway-helm at the pinned version and commits the rendered YAML alongside the version pin, so the image, the CVE patch set, and the manifest are all derived from a single value.
Renovate is wired up to bump the version (patch updates only), run the regen target via postUpgradeTasks, and open a dedicated PR. The companion tigera/operator PR replaces operator's local helm-template recipe with a cp out of the fetch-calico-crds clone (update-envoy-gateway-resources), so operator's version pin is gone entirely — make gen-versions keeps both gateway_api_resources.yaml and go.mod's github.com/envoyproxy/gateway line in lockstep with whatever calico publishes.
Paired with tigera/operator#4806.
Known limitation: the matching envoy-proxy and envoy-ratelimit versions in third_party/envoy-proxy/Makefile and third_party/envoy-ratelimit/Makefile are still bumped manually against the Envoy Gateway compatibility matrix (https://gateway.envoyproxy.io/news/releases/matrix/) — Renovate doesn't yet derive them from the envoy-gateway pin. Automating this is a follow-up.
Release note: