Fix tutorial review-app release and renderer startup

.controlplane/controlplane.yml

@@ -83,10 +83,10 @@ apps:
     <<: *common
     # match_if_app_name_starts_with is used to identify these "qa" apps.
     match_if_app_name_starts_with: true
-    # These review-app one-off defaults request app-sized resources and set a
-    # 15-minute server-side active deadline.
+    # Review-app one-off jobs need 2Gi to start the Rails image reliably and
+    # retain a 15-minute server-side active deadline.
     runner_job_default_cpu: "300m"
-    runner_job_default_memory: "1Gi"
+    runner_job_default_memory: "2Gi"
     runner_job_timeout: 900
     image_retention_days: 5
     stale_app_image_deployed_days: 5 # If the app is older than 5 days, the nightly automations will clean stale apps.

.controlplane/readme.md

@@ -593,7 +593,8 @@ renderer first, wait for it to become healthy, and then deploy `rails` plus
 
 The renderer workload uses the same application image as Rails, runs
 `react_on_rails_pro:pre_seed_renderer_cache` at container boot, and then starts
-`yarn node-renderer`. Rails gets `RENDERER_URL` from
+`node renderer/node-renderer.js`. Its non-login `bash -c` command preserves the
+Dockerfile's Node `PATH` during boot. Rails gets `RENDERER_URL` from
 `.controlplane/templates/app.yml` and reaches the renderer at
 `http://node-renderer.<app>.cpln.local:3800`.
 

.controlplane/shakacode-team.md

@@ -6,7 +6,7 @@ Deployments are handled by Control Plane configuration in this repo and GitHub A
 
 ### Renderer Workload
 - `node-renderer` is an app workload and deploys before `rails` through `deploy_order`.
-- `node-renderer` runs the React on Rails Pro boot seed before `yarn node-renderer` so the new renderer cache is warm before Rails rolls.
+- `node-renderer` runs the React on Rails Pro boot seed in a non-login shell before `node renderer/node-renderer.js` so the new renderer cache is warm before Rails rolls.
 - Rails reaches the renderer through `RENDERER_URL=http://node-renderer.<app>.cpln.local:3800`.
 - Keep `ROLLING_DEPLOY_TOKEN` populated in the app secret dictionary; Rails and the renderer use it for rolling-deploy bundle pulls.
 - For existing staging/production apps, populate `ROLLING_DEPLOY_TOKEN`, apply templates with `node-renderer`, validate staging, then promote production. Do not combine the production template cutover with missing secrets.

.controlplane/templates/node-renderer.yml

@@ -21,13 +21,13 @@ spec:
       image: {{APP_IMAGE_LINK}}
       args:
         - bash
-        - -lc
+        - -c
         - |
           # The rake task warns and continues on bundle fetch misses so rollout
           # does not wedge; unexpected task failures still stop the shell.
           set -e
           bundle exec rake react_on_rails_pro:pre_seed_renderer_cache
-          exec yarn node-renderer
+          exec node renderer/node-renderer.js
       ports:
         - number: 3800
           # The React on Rails Pro Node Renderer speaks cleartext HTTP/2 (h2c).

bin/test-cpflow-github-flow

@@ -37,13 +37,13 @@ container = spec.fetch("containers").fetch(0)
 
 expected_args = [
   "bash",
-  "-lc",
+  "-c",
   <<~'SHELL',
     # The rake task warns and continues on bundle fetch misses so rollout
     # does not wedge; unexpected task failures still stop the shell.
     set -e
     bundle exec rake react_on_rails_pro:pre_seed_renderer_cache
-    exec yarn node-renderer
+    exec node renderer/node-renderer.js
   SHELL
 ]
 expected_ports = [{ "number" => 3800, "protocol" => "http2" }]