[DE-4474]: Proxy Calico OSS e2e test binaries from S3 - #3007
Conversation
projectcalico/calico#13566 publishes version-matched Kubernetes e2e test binaries to s3://calico-public/<version>/files/e2e/ so a consumer can fetch one architecture instead of unpacking the ~1.2 GB release archive. The bucket only reaches the web through per-prefix proxies here, and /calico/charts/* was the only one, so those objects are currently unreachable from docs.tigera.io. Calico Enterprise needs no equivalent rule because downloads.tigera.io maps to its bucket root. The path mirrors the Enterprise layout, so a consumer resolves a binary the same way for either product. The rule is narrow rather than /calico/:version/files/* to keep the proxied surface to what is published today, and carries no force, so a real docs file still wins. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview succeeded!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
🟢 Approval recommended
The change is a small, narrowly-scoped Netlify redirect consistent with existing S3 proxy patterns in this repo and matches the stated routing behavior goal.
Pull request overview
Adds a Netlify proxy rewrite so Calico Open Source versioned Kubernetes e2e test binaries can be fetched from the calico-public S3 bucket via docs.tigera.io, aligning OSS download ergonomics with the Enterprise layout (without broadening the proxied surface beyond files/e2e).
Changes:
- Introduces a new Netlify
[[redirects]]rule for/calico/:version/files/e2e/*that proxies tohttps://calico-public.s3.amazonaws.com/:version/files/e2e/:splat. - Documents the intent and scope of the new proxy rule inline next to the existing OSS charts S3 proxy rule.
File summaries
| File | Description |
|---|---|
| netlify.toml | Adds a narrowly-scoped Netlify proxy rewrite for Calico OSS versioned e2e test binaries hosted in the public S3 bucket. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
@tigera/docs — ready for review when you have a moment. This is config-only: one proxy rule in Why it is needed: projectcalico/calico#13566 will publish Calico OSS e2e test binaries to Verified on the deploy preview (details in the description): the proxied path returns an S3 Happy to adjust the path shape if you would rather it live somewhere else in the URL space. |
|
Thanks for this, @Glen-Tigera . There's a scope question I'd like to ask before I approve. Generally, I don't want to include things like this unless they're part of a documented user workflow. If it's not, it should live elsewhere. Helm charts do this, for example. But nothing references the e2e binaries. The use case here seems to be internal tooling. What rules out GitHub release assets? Or something else? If the driver is Enterprise parity so banzai-core needs no change, I'd rather take the one-line change there than a permanent rule here — but tell me what I'm missing. |
Product Version(s):
Calico Open Source only — any release that publishes e2e test binaries, i.e. master onward once projectcalico/calico#13566 lands. Not applicable to Calico Enterprise or Calico Cloud.
Issue:
Link to docs preview:
https://deploy-preview-3007--calico-docs-preview-next.netlify.app
Nothing is published at the proxied path yet, so the preview cannot return a binary — but it does prove the routing, and the distinction is the whole point of this PR. Verified on the preview above:
/calico/v3.31.1/files/e2e/e2e-linux-amd64.test403 application/xml/calico/charts/index.yaml200 application/yaml/calico/v3.31.1/files/other/thing.txt404 text/htmlfiles/e2e/onlyBefore this change the first path returned the docs
404HTML, i.e. the request never reached S3. Once a Calico release publishes, it becomes200.SME review:
DOCS review:
Additional information:
Calico releases will publish version-matched Kubernetes e2e test binaries to
s3://calico-public/<version>/files/e2e/, so a consumer can fetch the one architecture it needs (~71 MB) rather than unpacking the ~1.2 GB release archive that also contains them.That bucket only reaches the web through the per-prefix proxies in
netlify.toml, and/calico/charts/*was the only one — so those objects are currently unreachable fromdocs.tigera.io. Calico Enterprise needs no equivalent rule becausedownloads.tigera.iomaps to its bucket root; this asymmetry is why a docs change is needed for Calico Open Source and not for Enterprise.Two deliberate choices:
/calico/:version/files/e2e/*rather than/calico/:version/files/*, to keep the proxied surface to what is actually published today.force. Matching the charts rule, so a real docs file always wins over the proxy. The paths cannot collide anyway: docs versions arelatest/3.30-style, while release versions carry avprefix.The path deliberately mirrors the Enterprise layout, so a consumer resolves a binary the same way for either product.
Ordering: harmless to merge before projectcalico/calico#13566 (the path simply has nothing behind it yet), and there is no benefit until that lands either. Happy either way — landing this first gives the publish side somewhere to point.
Merge checklist: