From 04795584ee4a46ce4f4ac0b7cc806053cc343e56 Mon Sep 17 00:00:00 2001 From: Codex Date: Tue, 19 May 2026 04:10:45 +0000 Subject: [PATCH] chore: pin dev lane to release v1 --- deploy.json | 6 +++--- docs/reference/ci.md | 11 +++++++---- docs/reference/dev-ci-runner.md | 4 +++- docs/reference/release-governance.md | 6 ++++++ 4 files changed, 19 insertions(+), 8 deletions(-) diff --git a/deploy.json b/deploy.json index e48ae47a..2e222e3f 100644 --- a/deploy.json +++ b/deploy.json @@ -85,17 +85,17 @@ { "id": "backend-core", "repo": "https://github.com/pikasTech/unidesk", - "commitId": "60060173933bb3c80aea5e48ecc21a73cf74f877" + "commitId": "12de3cdae50ffda0e0a01ecf114be5991f4155d9" }, { "id": "frontend", "repo": "https://github.com/pikasTech/unidesk", - "commitId": "c09beb0d5424b328f1592f065a8eba4e7ac5b93e" + "commitId": "12de3cdae50ffda0e0a01ecf114be5991f4155d9" }, { "id": "code-queue", "repo": "https://github.com/pikasTech/unidesk", - "commitId": "cea9988576f7b7eed81ee6b9e2a4b9800a334b33" + "commitId": "12de3cdae50ffda0e0a01ecf114be5991f4155d9" } ] } diff --git a/docs/reference/ci.md b/docs/reference/ci.md index d5161bcc..fb1c0bd7 100644 --- a/docs/reference/ci.md +++ b/docs/reference/ci.md @@ -19,12 +19,13 @@ Each commit CI run performs: - `git clone` and checkout of the requested repository revision. - `bun install --frozen-lockfile` at the repo root and `src/`, because `bun scripts/cli.ts check` compiles all `src/components` and needs the component workspace lockfile for frontend React dependencies. - `UNIDESK_D601_RUST_CHECK=1 bun scripts/cli.ts check --full --rust`, so Rust backend-core is checked only inside the D601 CI execution boundary. -- `code-queue-mgr` `/api/workdirs` contract smoke against a temporary PostgreSQL instance, asserting the stable manager route returns `ok: true` and includes the controlled `/workspace` option. -- Backend-core production artifact publication when enabled: build the requested pushed commit on D601, stamp Docker image labels, and push a commit-pinned image to the D601 loopback artifact registry. +- Application contract checks such as Code Queue `/api/workdirs`, using ordinary app fixtures or E2E paths rather than CI/CD infrastructure self-tests. - Temporary `code-queue-ci-read` Deployment and ClusterIP Service in `unidesk-ci`. - Code Queue read performance checks against the production PostgreSQL through `d601-tcp-egress-gateway`. - Manual dev desired-state smoke for Code Queue via `ci run-dev-e2e`, using the Git-pinned `code-queue` service commit from `origin/master:deploy.json#environments.dev`. +CI/CD bootstrap, repair and upgrade actions are infrastructure operations. They are manually tested and may be promoted directly to production when the infrastructure itself is the target; do not add CI jobs whose purpose is to prove that CI/CD can bootstrap or repair itself. + `ci install` also prewarms the D601 k3s containerd runtime with the Tekton entrypoint/workingdir helper images, `oven/bun:1-debian`, `alpine/git:2.45.2` and `unidesk-code-queue:dev`. Missing images are pulled through the node-local provider-gateway WS egress proxy and then imported into native k3s containerd with digests preserved, so PipelineRun pods do not hang on external registry pulls. Sustained pull throughput below 1 MB/s is treated as a provider/main-server network or proxy degradation first, not as a Dockerfile or application failure. Git clone and dependency downloads inside the repo check task use `d601-provider-egress-proxy.unidesk.svc.cluster.local:18789`; the NO_PROXY list keeps the in-cluster read service and D601 TCP egress gateway on the cluster network. @@ -41,6 +42,8 @@ CI/CD services should report their source commit, API/schema capability, support During a `release/v1` stabilization window, CI should continue using the implemented dev desired-state contract rather than adding split-lane infrastructure. The `origin/master:deploy.json#environments.dev` service pins may point at v1 stabilization commits for validation, but CI must print the manifest commit and service commits it used. Explicit `dev-v1` and `dev-master` support is a later infrastructure change after v1 is stable. +When the broken component is CI/CD itself, use manual smoke checks, runtime health, logs, commit metadata and operator review as the acceptance path. Do not block the repair on a new CI self-test for the CI/CD bootstrap path. + Steps that call the Kubernetes API directly clear inherited proxy variables so service-account HTTPS calls to `kubernetes.default.svc` do not accidentally use the Code Queue image's Docker Compose proxy defaults. The rollout poll reads the Deployment main resource rather than the `/status` subresource, keeping CI RBAC limited to the same app/service resources it creates and deletes. The performance probe scans recent Code Queue tasks until it finds one with trace steps, so a newly selected task without persisted step detail does not make the whole gate fail before measuring the trace endpoints. @@ -59,7 +62,7 @@ This means the CI service can read existing tasks, Trace summaries, Trace steps ## Backend-Core Artifact Publication -backend-core production image creation belongs to D601 CI, not to master server CD. The purpose is to keep Rust compilation, Docker build cache, dependency downloads and image push on the higher-resource D601 side while leaving production deployment with a small pull/recreate/verify surface. +backend-core production image creation belongs to a manual D601-side artifact producer action, not to master server CD and not to a CI/CD bootstrap self-test. The purpose is to keep Rust compilation, Docker build cache, dependency downloads and image push on the higher-resource D601 side while leaving production deployment with a small pull/recreate/verify surface. The CI artifact task must follow these rules: @@ -77,7 +80,7 @@ The artifact registry contract and CD consumption path are defined in `docs/refe `ci run-dev-e2e` is the manual dev desired-state smoke flow. The single authoritative reference for its Git-controlled runner script, short launcher, result directory and no-CD boundary is `docs/reference/dev-ci-runner.md`. -The current dev namespace e2e is a harness and smoke gate, not a full frontend/backend stack rollout. It does include a controlled Code Queue slice: D601 builds or reuses the `environments.dev.services[].id=code-queue` commit, imports the image into native k3s containerd, starts temporary PostgreSQL plus Code Queue scheduler/read/write Services in `unidesk-ci-e2e-`, and verifies the HTTP API through the Kubernetes API service proxy. The stable frontend/backend path `/api/microservices/code-queue/proxy/api/workdirs` is covered by the normal UniDesk e2e check `microservice:code-queue-workdirs`, while the CI repo check separately starts `code-queue-mgr` against temporary PostgreSQL and asserts its `/api/workdirs` contract. This remains CI-only and must not deploy persistent `unidesk-dev` or production resources. +The current dev namespace e2e is a harness and smoke gate, not a full frontend/backend stack rollout. It does include a controlled Code Queue slice: D601 builds or reuses the `environments.dev.services[].id=code-queue` commit, imports the image into native k3s containerd, starts temporary PostgreSQL plus Code Queue scheduler/read/write Services in `unidesk-ci-e2e-`, and verifies the HTTP API through the Kubernetes API service proxy. The stable frontend/backend path `/api/microservices/code-queue/proxy/api/workdirs` is covered by the normal UniDesk e2e check `microservice:code-queue-workdirs`. This remains CI-only and must not deploy persistent `unidesk-dev` or production resources. ## Performance Gate diff --git a/docs/reference/dev-ci-runner.md b/docs/reference/dev-ci-runner.md index 7cb89939..528df2df 100644 --- a/docs/reference/dev-ci-runner.md +++ b/docs/reference/dev-ci-runner.md @@ -85,6 +85,8 @@ The automatic path is intentionally single and narrow: The CLI must not upload the runner script body. Tekton dev e2e must not clone the private UniDesk repo itself; repo access and desired-state extraction happen once in the D601 host launcher under the manifest commit. The submitted launcher may contain only repo, full commit, script path, run id, environment, timeout, keep-namespace and fixed workspace path settings plus the fixed fetch/execute wrapper. If k3s, Tekton or the provider egress proxy is unavailable, the run fails with visible logs; it must not fall back to an alternate deployment path. +This runner validates application desired state. It is not the acceptance path for CI/CD infrastructure bootstrap, repair or upgrade; those infrastructure operations are manually tested and may be promoted directly to production when the infrastructure itself is the target. + ## Runner Contract The Git-controlled script must accept: @@ -104,7 +106,7 @@ scripts/ci/dev-e2e.sh \ The current script creates a Tekton `PipelineRun` for `pipeline/unidesk-dev-namespace-e2e`, stores the generated PipelineRun name in `pipelinerun.txt`, and writes a final `result.json` with `ok`, `status`, `runId`, `manifestCommit`, `pipelineRun`, `temporaryNamespace` and `finishedAt`. -The Tekton task creates a temporary namespace `unidesk-ci-e2e-` and may create only CI-owned smoke resources there: `postgres-dev`, `code-queue-scheduler-dev`, `code-queue-read-dev`, `code-queue-write-dev`, their ClusterIP Services and a per-run Secret/ConfigMap. It must not mutate `unidesk` or persistent `unidesk-dev`. Code Queue API validation must use ClusterIP Services and the Kubernetes API `services/.../proxy` subresource; NodePort, D601 host ports and direct public service exposure are forbidden. The smoke currently proves `/health`, `/live` and `/api/workdirs` GET/POST/DELETE on read/write/scheduler roles, giving follow-up Code Queue API fixes a reproducible CI target before production rollout. The stable frontend/backend proxy contract is checked by `microservice:code-queue-workdirs` in the normal UniDesk e2e harness and by the repo-check `code-queue-mgr` `/api/workdirs` smoke. +The Tekton task creates a temporary namespace `unidesk-ci-e2e-` and may create only CI-owned smoke resources there: `postgres-dev`, `code-queue-scheduler-dev`, `code-queue-read-dev`, `code-queue-write-dev`, their ClusterIP Services and a per-run Secret/ConfigMap. It must not mutate `unidesk` or persistent `unidesk-dev`. Code Queue API validation must use ClusterIP Services and the Kubernetes API `services/.../proxy` subresource; NodePort, D601 host ports and direct public service exposure are forbidden. The smoke currently proves `/health`, `/live` and `/api/workdirs` GET/POST/DELETE on read/write/scheduler roles, giving follow-up Code Queue API fixes a reproducible application target before production rollout. The stable frontend/backend proxy contract is checked by `microservice:code-queue-workdirs` in the normal UniDesk e2e harness. ## Commands diff --git a/docs/reference/release-governance.md b/docs/reference/release-governance.md index b61a8712..56d2e109 100644 --- a/docs/reference/release-governance.md +++ b/docs/reference/release-governance.md @@ -83,6 +83,12 @@ This split must be implemented explicitly in `deploy.json`, deploy planning, dep During a v1 stabilization window, the future split-lane implementation is deliberately deferred. The current `environments.dev` lane is reserved for v1 validation until the v1 release criteria are met, then the explicit split-lane work can proceed as a separate infrastructure change. +## CI/CD Infrastructure Repair + +CI/CD infrastructure bootstrap, repair and upgrade must not depend on a new CI job that tests the CI/CD bootstrap path itself. When the CI/CD infrastructure is the broken component, use manual validation: runtime health, logs, source commit metadata, capability endpoints, bounded smoke commands and operator review. + +Manual CI/CD infrastructure fixes may be promoted directly to production when production infrastructure is the intended target. The durable state still has to return to Git-backed desired state: any code, manifest, config or policy change that should survive must be committed and pushed after the repair. + ## Feature Flags Feature flags are short-lived risk controls, not a long-term architecture partitioning mechanism. Prefer release lines, service boundaries and deployment boundaries for durable divergence.