PINF-816: default readinessProbe on git-sync-relay's git-sync container

[danielhoherd]

Description

PINF-816: companion chart-side change to git-sync-relay's readiness-tracking fix (astronomer/git-sync-relay#76): that PR makes /readyz reflect the relay's most recent sync attempt instead of only its first one at startup, but nothing wired that endpoint to an actual k8s probe — the gitSyncRelay.gitSync container had no readinessProbe/livenessProbe default at all (both {} in values.yaml).

Without a probe, a Deployment's Gitsync URL edited to something invalid produced no k8s-visible signal: the relay pod stayed Ready forever once its first sync had succeeded, silently failing every later poll/webhook cycle in the background.

Fix: a hardcoded readinessProbe fallback (httpGet /readyz on gitSync.webhookPort), following the same {{- if <values> }}...{{- else }}<default>{{- end }} pattern this template already uses for the git-daemon container's own liveness/startup defaults. Still fully overridable via gitSyncRelay.gitSync.readinessProbe.

Deliberately readinessProbe only, not livenessProbe: restarting the pod cannot fix a bad repo URL or revoked credentials, so tying liveness to sync health would just crash-loop the pod pointlessly instead of surfacing the actual problem.

This closes the loop with commander's existing WaitForDeployment/WaitForReady mechanism with no commander-side changes needed: it already discovers Deployments by release=<name>,tier=airflow (this Deployment already carries that label) and blocks/times out (default 300s) on status.readyReplicas < desired, which depends on pod readinessProbe passing. So a bad URL now makes this readinessProbe fail → readyReplicas drops → WaitForDeployment times out → commander reports a real, named deploy failure instead of a silently-degraded pod.

Kubelet probe traffic bypasses this chart's restrictive git-sync-relay NetworkPolicy (probes go from node to pod directly, never through the CNI's policy-enforced path) — confirmed this is standard behavior, not something needing an explicit allow-rule here.

Related Issues

• PINF-816
• Companion PR: astronomer/git-sync-relay#76 (the actual /readyz logic this probe depends on)

Testing

• tests/chart/test_git_sync_relay_deployment.py's default-values test updated to assert the new readinessProbe body instead of asserting its absence; the existing "no hardcoded fallback, customer-configurable only" comment/assertions for livenessProbe/startupProbe are unchanged (still true — only readinessProbe gets a default). The explicit-override test elsewhere in the same file (which sets readinessProbe/livenessProbe directly) is unaffected since it never hits the new {{- else }} branch.
• uv run pytest tests/chart/test_git_sync_relay_deployment.py — 155 passed.
• uv run pytest tests/chart/ (full suite) — 1090 passed, 46 skipped (pre-existing).

[Copilot]

Pull request overview

This PR adds a default Kubernetes readinessProbe to the umbrella chart’s git-sync-relay git-sync container so that the relay’s /readyz health signal (now reflecting the most recent sync attempt) is actually wired into Deployment readiness, allowing failed syncs (e.g., bad repo URL) to surface as NotReady rather than silently remaining Ready.

Changes:

• Add a hardcoded readinessProbe fallback (httpGet /readyz on gitSyncRelay.gitSync.webhookPort) when gitSyncRelay.gitSync.readinessProbe is unset/empty.
• Update the chart render test to assert the new default readinessProbe and keep liveness/startup behavior customer-configurable-only.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
templates/git-sync-relay/git-sync-relay-deployment.yaml	Adds a default readinessProbe fallback for the git-sync container pointing at /readyz.
tests/chart/test_git_sync_relay_deployment.py	Updates default-values assertions to expect the new git-sync readinessProbe.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.