Gitea's egress rule into ai named only the wiki-index pod, so the new webhook (hook 17 on k.renner/notes → wiki.ai.svc:8080/webhook) timed out: Post ... context deadline exceeded (Client.Timeout exceeded while awaiting headers) in Gitea's log. The rule now also admits the wiki pod on 8080. The service itself answers (a signed request through the ingress gets the expected 403 on a bad signature).
Verification after merge: POST /repos/k.renner/notes/hooks/17/tests and a sync done ... Skipped = True line in the wiki pod log.
Gitea's egress rule into `ai` named only the `wiki-index` pod, so the new webhook (hook 17 on k.renner/notes → `wiki.ai.svc:8080/webhook`) timed out: `Post ... context deadline exceeded (Client.Timeout exceeded while awaiting headers)` in Gitea's log. The rule now also admits the `wiki` pod on 8080. The service itself answers (a signed request through the ingress gets the expected 403 on a bad signature).
Verification after merge: `POST /repos/k.renner/notes/hooks/17/tests` and a `sync done ... Skipped = True` line in the wiki pod log.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Gitea's egress to ai was scoped to the wiki-index pod; deliveries to
wiki.ai.svc timed out (hook 17, 2026-09-24).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
🤖Automated review — model CLI default (complexity: unknown), commit 3b0c42473aa40d03aaa3f283750e385006797614.
Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.
Summary
Adds a second matchLabels entry (app.kubernetes.io/name: wiki) to the existing egress rule in gitea-ns.yaml's default-deny policy, alongside the pre-existing wiki-index entry, so pods in the gitea namespace can reach the wiki pod on port 8080. No blocking issues.
Tests
No automated tests apply to network-policy manifests in this repo (none exist for the sibling policies either). The PR body describes concrete post-merge verification (POST /repos/k.renner/notes/hooks/17/tests returning success and a sync done ... Skipped = True line in the wiki pod log), which is the appropriate way to validate a CiliumNetworkPolicy change like this — I can't execute it from a static review, but the described check is the right one.
Verification performed
Confirmed the ingress side already permits this traffic: kubernetes/infrastructure/network-policies/ai-ns.yaml:154-174 (the wiki CiliumNetworkPolicy) already allows ingress from namespace: gitea, app.kubernetes.io/name: gitea on port 8080 — this PR closes the missing egress half of that path, matching the bug description exactly.
Confirmed port 8080 matches the wiki deployment's container/service port (kubernetes/apps/wiki/deployment.yaml:77,129).
Confirmed the multi-entry matchLabels list under a single toEndpoints rule is valid Cilium OR-semantics and matches the repo's own established idiom for this exact case — the wiki and wiki-index ingress rules in ai-ns.yaml:164-170 and :189-196 already combine two matchLabels entries (traefik, gitea) under one fromEndpoints list rather than as two separate top-level rules.
The edit is minimal and doesn't touch the wiki-index entry or any unrelated rule.
Recommendation
Looks reasonable — no blocking issues; comments above are optional.
🤖 **Automated review** — model `CLI default` (complexity: unknown), commit `3b0c42473aa40d03aaa3f283750e385006797614`.
> Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review.
---
## Summary
Adds a second `matchLabels` entry (`app.kubernetes.io/name: wiki`) to the existing egress rule in `gitea-ns.yaml`'s `default-deny` policy, alongside the pre-existing `wiki-index` entry, so pods in the `gitea` namespace can reach the `wiki` pod on port 8080. No blocking issues.
## Tests
No automated tests apply to network-policy manifests in this repo (none exist for the sibling policies either). The PR body describes concrete post-merge verification (`POST /repos/k.renner/notes/hooks/17/tests` returning success and a `sync done ... Skipped = True` line in the wiki pod log), which is the appropriate way to validate a CiliumNetworkPolicy change like this — I can't execute it from a static review, but the described check is the right one.
## Verification performed
- Confirmed the ingress side already permits this traffic: `kubernetes/infrastructure/network-policies/ai-ns.yaml:154-174` (the `wiki` CiliumNetworkPolicy) already allows ingress from `namespace: gitea, app.kubernetes.io/name: gitea` on port 8080 — this PR closes the missing egress half of that path, matching the bug description exactly.
- Confirmed port 8080 matches the `wiki` deployment's container/service port (`kubernetes/apps/wiki/deployment.yaml:77,129`).
- Confirmed the multi-entry `matchLabels` list under a single `toEndpoints` rule is valid Cilium OR-semantics and matches the repo's own established idiom for this exact case — the `wiki` and `wiki-index` ingress rules in `ai-ns.yaml:164-170` and `:189-196` already combine two `matchLabels` entries (traefik, gitea) under one `fromEndpoints` list rather than as two separate top-level rules.
- The edit is minimal and doesn't touch the `wiki-index` entry or any unrelated rule.
## Recommendation
Looks reasonable — no blocking issues; comments above are optional.
<!-- pr-review:sha=3b0c42473aa40d03aaa3f283750e385006797614 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Gitea's egress rule into
ainamed only thewiki-indexpod, so the new webhook (hook 17 on k.renner/notes →wiki.ai.svc:8080/webhook) timed out:Post ... context deadline exceeded (Client.Timeout exceeded while awaiting headers)in Gitea's log. The rule now also admits thewikipod on 8080. The service itself answers (a signed request through the ingress gets the expected 403 on a bad signature).Verification after merge:
POST /repos/k.renner/notes/hooks/17/testsand async done ... Skipped = Trueline in the wiki pod log.🤖 Generated with Claude Code
🤖 Automated review — model
CLI default(complexity: unknown), commit3b0c42473aa40d03aaa3f283750e385006797614.Summary
Adds a second
matchLabelsentry (app.kubernetes.io/name: wiki) to the existing egress rule ingitea-ns.yaml'sdefault-denypolicy, alongside the pre-existingwiki-indexentry, so pods in thegiteanamespace can reach thewikipod on port 8080. No blocking issues.Tests
No automated tests apply to network-policy manifests in this repo (none exist for the sibling policies either). The PR body describes concrete post-merge verification (
POST /repos/k.renner/notes/hooks/17/testsreturning success and async done ... Skipped = Trueline in the wiki pod log), which is the appropriate way to validate a CiliumNetworkPolicy change like this — I can't execute it from a static review, but the described check is the right one.Verification performed
kubernetes/infrastructure/network-policies/ai-ns.yaml:154-174(thewikiCiliumNetworkPolicy) already allows ingress fromnamespace: gitea, app.kubernetes.io/name: giteaon port 8080 — this PR closes the missing egress half of that path, matching the bug description exactly.wikideployment's container/service port (kubernetes/apps/wiki/deployment.yaml:77,129).matchLabelslist under a singletoEndpointsrule is valid Cilium OR-semantics and matches the repo's own established idiom for this exact case — thewikiandwiki-indexingress rules inai-ns.yaml:164-170and:189-196already combine twomatchLabelsentries (traefik, gitea) under onefromEndpointslist rather than as two separate top-level rules.wiki-indexentry or any unrelated rule.Recommendation
Looks reasonable — no blocking issues; comments above are optional.