scripts/deployment/one-click-deploy.sh cannot succeed today. It fails at its first gate, and even if that gate were removed the rollout it produces could not become ready. Splitting this out of #1121 / #1122, where fixing only the first gate would have made the second failure reachable.
1. Precheck requires files that do not exist
REQUIRED_FILES lists mcp_server.py and learning_app_processor.py. Neither exists anywhere in the repository:
$ find . -name mcp_server.py -o -name learning_app_processor.py | grep -v node_modules
(no output)
The validation loop exit 1s on the first miss, so the script aborts before any later step runs. Three other entries in the same array are also stale (k8s/... rather than infrastructure/k8s/...).
2. The built image cannot satisfy the deployment that consumes it
The script builds enhanced-framework:latest from infrastructure/docker/Dockerfile.production, which after #1122 is a Python/uvicorn image:
- listens on 8000
- serves
/health and /readyz (src/youtube_extension/main.py)
infrastructure/k8s/production/deployment.yaml runs a container named enhanced-framework from that same tag, but configures it as a Node app:
- name: enhanced-framework
image: enhanced-framework:latest
ports:
- containerPort: 3000
env:
- name: NODE_ENV
value: "production"
- name: PORT
value: "3000"
livenessProbe:
httpGet: { path: /health, port: 3000 }
readinessProbe:
httpGet: { path: /ready, port: 3000 }Three independent mismatches: runtime (Node vs Python), port (3000 vs 8000), and readiness path (/ready vs /readyz).
Note the same manifest already has a separate mcp-server container on python:3.11-slim listening on 8000 — so the Python service is accounted for elsewhere, and enhanced-framework appears to be intended as the frontend (consistent with NODE_ENV/PORT=3000, i.e. apps/web).
Why this was not fixed in #1122
#1122 is scoped to #1121 (harden the production image and de-vacuify its tests). Correcting only the precheck would have turned a script that fails fast into one that builds an image and then produces a Deployment that never passes readiness — strictly worse. The path corrections were therefore reverted from that PR.
Suggested resolution
Decide the intended topology first, then make script and manifest agree:
- If
enhanced-framework is the Next.js frontend: build it from the web app's Dockerfile, keep 3000, and align the readiness path with what that app serves.
- If it is the Python backend: change the manifest to containerPort 8000, drop
NODE_ENV/PORT, and point the readiness probe at /readyz (or add a /ready alias in main.py).
Either way, refresh REQUIRED_FILES to paths that exist, and add a CI check that every path in that array resolves so this cannot rot again.
scripts/deployment/one-click-deploy.sh cannot succeed today. It fails at its first gate, and even if that gate were removed the rollout it produces could not become ready. Splitting this out of #1121 / #1122, where fixing only the first gate would have made the second failure reachable.
1. Precheck requires files that do not exist
REQUIRED_FILESlistsmcp_server.pyandlearning_app_processor.py. Neither exists anywhere in the repository:The validation loop
exit 1s on the first miss, so the script aborts before any later step runs. Three other entries in the same array are also stale (k8s/...rather thaninfrastructure/k8s/...).2. The built image cannot satisfy the deployment that consumes it
The script builds
enhanced-framework:latestfrominfrastructure/docker/Dockerfile.production, which after #1122 is a Python/uvicorn image:/healthand/readyz(src/youtube_extension/main.py)infrastructure/k8s/production/deployment.yamlruns a container namedenhanced-frameworkfrom that same tag, but configures it as a Node app:Three independent mismatches: runtime (Node vs Python), port (3000 vs 8000), and readiness path (
/readyvs/readyz).Note the same manifest already has a separate
mcp-servercontainer onpython:3.11-slimlistening on 8000 — so the Python service is accounted for elsewhere, andenhanced-frameworkappears to be intended as the frontend (consistent withNODE_ENV/PORT=3000, i.e.apps/web).Why this was not fixed in #1122
#1122 is scoped to #1121 (harden the production image and de-vacuify its tests). Correcting only the precheck would have turned a script that fails fast into one that builds an image and then produces a Deployment that never passes readiness — strictly worse. The path corrections were therefore reverted from that PR.
Suggested resolution
Decide the intended topology first, then make script and manifest agree:
enhanced-frameworkis the Next.js frontend: build it from the web app's Dockerfile, keep 3000, and align the readiness path with what that app serves.NODE_ENV/PORT, and point the readiness probe at/readyz(or add a/readyalias inmain.py).Either way, refresh
REQUIRED_FILESto paths that exist, and add a CI check that every path in that array resolves so this cannot rot again.