fix: keep dev code queue deploy target side

This commit is contained in:
Codex
2026-05-18 03:37:53 +00:00
parent e5a5bed0f7
commit c514b6ca9e
4 changed files with 20 additions and 12 deletions
+2 -2
View File
@@ -75,7 +75,7 @@ Phase 5 introduces the dev Code Queue execution manifest at `src/components/micr
All dev Code Queue components must use `unidesk-dev-runtime-config` and `unidesk-dev-runtime-secrets`, connect to `postgres-dev.../unidesk_dev`, write logs and state under `/home/ubuntu/unidesk-dev-code-queue-deploy/state`, and expose HTTP on 4222 only as ClusterIP services. The scheduler uses `CODE_QUEUE_MAIN_PROVIDER_ID=D601-dev`, `CODE_QUEUE_WORKDIR=/workspace-dev`, `CODE_QUEUE_REMOTE_WORKDIR=/home/ubuntu/unidesk-dev-workspace`, disables ClaudeQQ notifications by default, and does not use the production `d601-tcp-egress-gateway` or production PostgreSQL route.
`deploy apply --env dev --service code-queue` fetches `origin/deploy/dev:deploy.json`, materializes the requested source commit on D601, copies the dev Code Queue control manifest, narrows it to Code Queue dev objects, replaces placeholders with the requested commit and `unidesk-code-queue:dev`, builds on D601, imports the image into native k3s containerd, applies only `unidesk-dev` objects and stamps the dev Deployments. Because Code Queue carries the agent toolchain and browser/runtime dependencies, dev builds may reuse an existing D601 `unidesk-code-queue:d601-build-base` or `unidesk-code-queue:d601` image when the dev build-base tag is absent, and the deploy executor allows a longer Code Queue build window than lightweight services. This first dev execution slice proves deployability, health and dev database isolation; wiring the dev frontend stable `code-queue` route through a dev `code-queue-mgr` is a separate later phase.
`deploy apply --env dev --service code-queue` fetches `origin/deploy/dev:deploy.json`, materializes the requested source commit on D601, uses the dev Code Queue control manifest from that D601 materialized commit, narrows it to Code Queue dev objects, replaces placeholders with the requested commit and `unidesk-code-queue:dev`, builds on D601, imports the image into native k3s containerd, applies only `unidesk-dev` objects and stamps the dev Deployments. Because Code Queue carries the agent toolchain and browser/runtime dependencies, dev builds may reuse an existing D601 `unidesk-code-queue:d601-build-base` or `unidesk-code-queue:d601` image when the dev build-base tag is absent, and the deploy executor allows a longer Code Queue build window than lightweight services. The scheduler has an explicit 5Gi memory limit, and all dev Code Queue containers must set CPU limits so the namespace `LimitRange` does not inject a quota-breaking default CPU limit. This first dev execution slice proves deployability, health and dev database isolation; wiring the dev frontend stable `code-queue` route through a dev `code-queue-mgr` is a separate later phase.
## CLI
@@ -100,7 +100,7 @@ Target-side build is the only standard deployment mode. The controller may run o
The reconciler distributes only repository URL, commit ID, Dockerfile path, build context and the existing deployment manifest/compose declaration. It must not distribute large Docker images between hosts as the default path, and it must not accept `docker commit` images, dirty worktrees or hand-mutated runtime containers as deployment truth.
Each target fetches the remote repository, resolves the requested commit to a full 40 character SHA and exports tracked files with `git archive`. Build contexts are created from that archive, not from the operator's current working tree.
Each target fetches the remote repository, resolves the requested commit to a full 40 character SHA and exports tracked files with `git archive`. Build contexts are created from that archive, not from the operator's current working tree. Environment applies such as `deploy apply --env dev` must not upload Kubernetes manifests or source files from the master server worktree; the target-side materialized commit is the source for Dockerfile, build context and k3s control manifests. The master server side may only do lightweight CLI orchestration, environment ref reading and remote command dispatch.
## One-Shot Build Proxy
+5 -8
View File
@@ -1070,16 +1070,13 @@ function claudeqqDeployAssetOverlayCommands(): string[] {
function syncK8sControlManifestsScript(service: UniDeskMicroserviceConfig): string {
if (isDevK3sDeployService(service)) {
const manifest = k8sManifestPath(service);
if (!existsSync(rootPath(manifest))) throw new Error(`${service.id} dev k3s control manifest missing: ${manifest}`);
const encoded = Buffer.from(readFileSync(rootPath(manifest), "utf8"), "utf8").toString("base64");
return [
"set -euo pipefail",
`target_root=${shellQuote(targetWorkDir(service))}`,
`relative_path=${shellQuote(manifest)}`,
"target_file=\"$target_root/$relative_path\"",
"mkdir -p \"$(dirname \"$target_file\")\"",
`printf %s ${shellQuote(encoded)} | base64 -d > "$target_file"`,
"printf 'synced_k3s_control_manifest=%s\\n' \"$target_file\"",
"test -f \"$target_file\"",
"printf 'target_k3s_control_manifest=%s\\n' \"$target_file\"",
].join("\n");
}
if (service.deployment.mode !== "k3sctl-managed" || isUnideskRepo(service.repository.url)) return "";
@@ -2110,7 +2107,8 @@ async function applyOneService(config: UniDeskConfig, service: UniDeskMicroservi
const controlManifestSyncScript = syncK8sControlManifestsScript(service);
if (controlManifestSyncScript.length > 0) {
const controlManifestSync = await step(config, service, "sync-k3s-control-manifests", controlManifestSyncScript, targetIsMain(service) ? repoRoot : "/home/ubuntu", 90_000, !targetIsMain(service));
const controlManifestStep = isDevK3sDeployService(service) ? "verify-target-k3s-manifest" : "sync-k3s-control-manifests";
const controlManifestSync = await step(config, service, controlManifestStep, controlManifestSyncScript, targetIsMain(service) ? repoRoot : "/home/ubuntu", 90_000, !targetIsMain(service));
if (!pushStep(steps, controlManifestSync)) return { ok: false, serviceId: service.id, startedAt, finishedAt: nowIso(), resolvedCommit, before, steps };
}
@@ -2296,9 +2294,8 @@ export async function runDeployCommand(config: UniDeskConfig | null, args: strin
throw new Error(`deploy apply --env dev currently supports only ${[...devApplySupportedServiceIds].join(", ")}; unsupported selected services: ${unsupported.join(", ")}`);
}
if (config === null) throw new Error("deploy apply --env dev requires config.json");
const resolved = resolveManifestCommits(manifest, options.serviceId);
if (!options.runNow) return applyJob(config, args, options);
return await runApplyNow(config, resolved, options);
return await runApplyNow(config, manifest, options);
}
if (config === null) throw new Error("deploy local manifest mode requires config.json");
const manifest = resolveManifestCommits(await readDeployManifest(options.file), options.serviceId);
@@ -224,6 +224,13 @@ spec:
periodSeconds: 10
timeoutSeconds: 3
failureThreshold: 6
resources:
requests:
cpu: 25m
memory: 64Mi
limits:
cpu: 100m
memory: 128Mi
volumes:
- name: script
configMap:
@@ -406,7 +413,8 @@ spec:
cpu: 150m
memory: 384Mi
limits:
memory: 3Gi
cpu: 800m
memory: 5Gi
volumes:
- name: docker-sock
hostPath:
@@ -568,6 +576,7 @@ spec:
cpu: 80m
memory: 192Mi
limits:
cpu: 250m
memory: 768Mi
volumes:
- name: repo
@@ -710,6 +719,7 @@ spec:
cpu: 80m
memory: 192Mi
limits:
cpu: 250m
memory: 768Mi
volumes:
- name: repo
@@ -40,10 +40,11 @@ spec:
cpu: 50m
memory: 96Mi
default:
cpu: 250m
memory: 512Mi
max:
cpu: "2"
memory: 2Gi
memory: 5Gi
---
apiVersion: v1
kind: Secret