@catladder/cli 0.0.0-next-f2614a3a → 0.0.0-next-78d43d4a

package/dist/bundles/skills/catladder-migrate-ci-backend/SKILL.md

@@ -193,16 +193,40 @@ See the `catladder-releases` skill for how the release jobs differ
 
 ## Step 7 — registry and the first run
 
-The container registry changes with the backend: `$CI_REGISTRY_IMAGE` on
-GitLab, `ghcr.io/<owner>/<repo>` on GitHub. Consequences to state
-explicitly:
-
-- The first pipeline on the new backend **rebuilds every job image and
-  every app image** — it will be slow, and that is expected, not a bug.
-- The deploy target must be able to **pull from the new registry**.
-  catladder does not manage image-pull credentials on the cluster or on
-  Cloud Run, so check GHCR package visibility / the pull secret with
-  whoever owns the target *before* pointing a real environment at it.
+The **job images** (the catladder runner images) always live in the CI
+system's own registry, so they change host with the backend:
+`$CI_REGISTRY_IMAGE` on GitLab, `ghcr.io/<owner>/<repo>` on GitHub. The
+first pipeline on the new backend therefore **rebuilds every job image**
+— it will be slow, and that is expected, not a bug.
+
+Where the **app image** goes depends on the deploy type:
+
+- **`google-cloudrun`** — the image goes to Google Artifact Registry
+  (`<region>-docker.pkg.dev/<projectId>/catladder-deploy/…`) on both
+  backends. Cloud Run can only pull from AR/GCR, so a backend migration
+  does not move the app image at all. Nothing to do here.
+- **`kubernetes`** — the app image lives in the CI registry and does
+  move. catladder handles the pull itself: every deploy runs
+  `kubernetesCreateSecret`, which writes a `docker-registry` secret
+  (`gitlab-registry-<component>`) into the namespace, and the chart wires
+  it in as `imagePullSecrets`. Note the secret keeps its historical name
+  on both backends.
+
+The credential behind that secret differs per backend, and this is the
+one thing to raise before a kubernetes component moves to GitHub:
+
+- **GitLab** provisions a durable one automatically —
+  `catladder project setup` creates a `gitlab-deploy-token` (scope
+  `read_registry`), GitLab exposes it to jobs as `CI_DEPLOY_USER` /
+  `CI_DEPLOY_PASSWORD`, and `project doctor` fails when it is missing.
+- **GitHub has no equivalent.** The deploy falls back to the workflow
+  token, which expires with the run: the initial pull succeeds and the
+  job goes green, but a pod rescheduled later cannot re-pull —
+  `ImagePullBackOff` weeks after a deploy that looked fine. Until that
+  is solved (catladder issue #75), a project moving kubernetes to GitHub
+  must supply a long-lived registry credential itself, declared as
+  secrets named `CI_DEPLOY_USER` / `CI_DEPLOY_PASSWORD` (a PAT with
+  `read:packages`), which take precedence in the deploy.
 
 ## Step 8 — run both, compare, then cut over
 

package/dist/skills/catladder-migrate-ci-backend/SKILL.md

@@ -193,16 +193,40 @@ See the `catladder-releases` skill for how the release jobs differ
 
 ## Step 7 — registry and the first run
 
-The container registry changes with the backend: `$CI_REGISTRY_IMAGE` on
-GitLab, `ghcr.io/<owner>/<repo>` on GitHub. Consequences to state
-explicitly:
-
-- The first pipeline on the new backend **rebuilds every job image and
-  every app image** — it will be slow, and that is expected, not a bug.
-- The deploy target must be able to **pull from the new registry**.
-  catladder does not manage image-pull credentials on the cluster or on
-  Cloud Run, so check GHCR package visibility / the pull secret with
-  whoever owns the target *before* pointing a real environment at it.
+The **job images** (the catladder runner images) always live in the CI
+system's own registry, so they change host with the backend:
+`$CI_REGISTRY_IMAGE` on GitLab, `ghcr.io/<owner>/<repo>` on GitHub. The
+first pipeline on the new backend therefore **rebuilds every job image**
+— it will be slow, and that is expected, not a bug.
+
+Where the **app image** goes depends on the deploy type:
+
+- **`google-cloudrun`** — the image goes to Google Artifact Registry
+  (`<region>-docker.pkg.dev/<projectId>/catladder-deploy/…`) on both
+  backends. Cloud Run can only pull from AR/GCR, so a backend migration
+  does not move the app image at all. Nothing to do here.
+- **`kubernetes`** — the app image lives in the CI registry and does
+  move. catladder handles the pull itself: every deploy runs
+  `kubernetesCreateSecret`, which writes a `docker-registry` secret
+  (`gitlab-registry-<component>`) into the namespace, and the chart wires
+  it in as `imagePullSecrets`. Note the secret keeps its historical name
+  on both backends.
+
+The credential behind that secret differs per backend, and this is the
+one thing to raise before a kubernetes component moves to GitHub:
+
+- **GitLab** provisions a durable one automatically —
+  `catladder project setup` creates a `gitlab-deploy-token` (scope
+  `read_registry`), GitLab exposes it to jobs as `CI_DEPLOY_USER` /
+  `CI_DEPLOY_PASSWORD`, and `project doctor` fails when it is missing.
+- **GitHub has no equivalent.** The deploy falls back to the workflow
+  token, which expires with the run: the initial pull succeeds and the
+  job goes green, but a pod rescheduled later cannot re-pull —
+  `ImagePullBackOff` weeks after a deploy that looked fine. Until that
+  is solved (catladder issue #75), a project moving kubernetes to GitHub
+  must supply a long-lived registry credential itself, declared as
+  secrets named `CI_DEPLOY_USER` / `CI_DEPLOY_PASSWORD` (a PAT with
+  `read:packages`), which take precedence in the deploy.
 
 ## Step 8 — run both, compare, then cut over
 

package/package.json

@@ -53,7 +53,7 @@
     }
   ],
   "license": "MIT",
-  "version": "0.0.0-next-f2614a3a",
+  "version": "0.0.0-next-78d43d4a",
   "scripts": {
     "lint": "eslint \"src/**/*.ts\"",
     "lint:fix": "eslint \"src/**/*.ts\" --fix",