mirrors/pikasTech-unidesk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: extend k3s artifact consumers

Browse Source
This commit is contained in:
Codex
2026-05-20 02:58:41 +00:00
parent 15a1a8b21a
commit 595de3d320
28 changed files with 1003 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/dev-environment.md
+14 -11
View File
@@ -38,12 +38,13 @@ The target release-governance model is to split stable maintenance validation fr
During a `release/v1` stabilization window, this same implemented `environments.dev` lane is temporarily reserved for v1 validation. Use pushed commits and explicit `deploy.json` pins to validate v1 fixes; do not add a parallel `dev-v1`/`dev-master` schema in the middle of the stabilization window unless that split is the blocker for v1. The detailed phase rule lives in `docs/reference/release-governance.md`.
The persistent dev rollout currently supports only:
The persistent dev rollout currently supports:
- `backend-core`
- `frontend`
- `backend-core` as a D601 target-side build.
- `frontend`, `decision-center`, `mdtodo`, `claudeqq` and `code-queue` as D601 registry artifact consumers in `unidesk-dev`.
- `baidu-netdisk` as the main-server direct user-service artifact validation sample.
`baidu-netdisk` may appear in `environments.dev.services` as the first main-server direct user-service artifact validation sample. `deploy apply --env dev --service baidu-netdisk` consumes the D601 registry artifact and validates the main-server Compose service; it is not a persistent D601 k3s dev workload. `code-queue` is present in `environments.dev.services` only so `ci run-dev-e2e` can build a Git-pinned Code Queue image and run a temporary namespace smoke. It is not part of persistent dev apply: `deploy apply --env dev --service code-queue` must still be rejected. Decision Center, k3sctl-adapter and other D601 services are not part of persistent dev apply yet. Their smoke validation stays under `ci run-dev-e2e` or service-specific future designs. The `environments.dev.ci` declaration and short launcher runner are owned by `docs/reference/dev-ci-runner.md`.
`deploy apply --env dev --service baidu-netdisk` consumes the D601 registry artifact and validates the main-server Compose service; it is not a persistent D601 k3s dev workload. `deploy apply --env dev --service code-queue` is intentionally dev-only and may mutate only `unidesk-dev` Code Queue scheduler/read/write/provider-egress-proxy objects. `deploy apply --env prod --service code-queue` must remain unsupported. The `environments.dev.ci` declaration and short launcher runner are owned by `docs/reference/dev-ci-runner.md`.
## Rust Backend-Core Boundary
@@ -69,20 +70,20 @@ Rust checking is enabled only when the process is already running inside the D60
## Dev Deploy Path
`deploy apply --env dev --service backend-core|frontend` is the controlled persistent dev rollout path. The controller runs on the master server, but the heavy work runs on D601. `backend-core` still uses the constrained dev target-side build path; `frontend` consumes the CI-published commit-pinned artifact from the D601 registry.
`deploy apply --env dev --service backend-core|frontend|decision-center|mdtodo|claudeqq|code-queue` is the controlled persistent dev rollout path for D601 dev workloads. The controller runs on the master server, but the heavy work runs on D601. `backend-core` still uses the constrained dev target-side build path; the other listed services consume CI-published commit-pinned artifacts from the D601 registry.
1. Fetch `origin/master:deploy.json#environments.dev` and resolve the requested service commit to a full SHA.
2. Dispatch to D601 through the existing provider-gateway/Host SSH maintenance capability.
3. On D601, fetch/export the requested Git commit through the node-local provider-gateway egress proxy `http://127.0.0.1:18789`.
4. For backend-core, use the target-side commit as the source for Dockerfile, build context and dev k3s manifest, then build the service image on D601 Docker.
5. For frontend, require the existing registry image `127.0.0.1:5000/unidesk/frontend:<commit>` produced by `ci publish-user-service --service frontend`; do not build frontend source in the dev target.
6. Import the backend-core build output or frontend artifact into native k3s containerd at `/run/k3s/containerd/containerd.sock`.
5. For artifact consumers, require the existing registry image `127.0.0.1:5000/unidesk/<service-id>:<commit>` produced by `ci publish-user-service --service <service-id>`; do not build that service source in the dev target.
6. Import the backend-core build output or registry artifact into native k3s containerd at `/run/k3s/containerd/containerd.sock`.
7. Apply only the selected `unidesk-dev` Service/Deployment objects from the dev manifest.
8. For `frontend`, sync auth/session settings from main-server `config.json.auth` into the dev runtime Secret/ConfigMap before rollout.
9. Stamp the Deployment with `UNIDESK_DEPLOY_*` env and `unidesk.ai/deploy-*` annotations.
10. Verify health through the Kubernetes API service proxy and require the live commit to match the requested commit.
The dev path is not a fallback system. If GitHub fetch, provider-gateway egress, Docker build for backend-core, frontend artifact lookup, native k3s, containerd import, kubectl apply or live health verification fails, the job fails with logs. It must not fall back to building frontend source on the dev target, building on the master server, using a dirty worktree, direct D601 public ports, NodePort, or another deployment command.
The dev path is not a fallback system. If GitHub fetch, provider-gateway egress, Docker build for backend-core, artifact lookup, native k3s, containerd import, kubectl apply or live health verification fails, the job fails with logs. It must not fall back to building artifact-consumer source on the dev target, building on the master server, using a dirty worktree, direct D601 public ports, NodePort, hostPort, provider-gateway business HTTP, or another deployment command. k3s-managed health verification must use the Kubernetes API service proxy.
## DevOps Hygiene
@@ -96,13 +97,13 @@ Use this sequence for backend-core Rust and frontend dev work:
2. Run local non-Rust checks on the master server, for example `bun scripts/cli.ts check --files --scripts-typecheck --compose --logs`.
3. Commit and push the code to `origin master`; `deploy apply --env dev` cannot deploy unpushed local changes.
4. Update `deploy.json` `environments.dev.services` so `backend-core` and `frontend` point at the pushed commit, then commit and push that manifest update.
5. For frontend changes, publish the artifact first: `bun scripts/cli.ts ci publish-user-service --service frontend --commit <full-sha> --wait-ms 1200000`.
5. For artifact-consumer changes, publish the artifact first: `bun scripts/cli.ts ci publish-user-service --service <frontend|decision-center|mdtodo|claudeqq|code-queue> --commit <full-sha> --wait-ms 1200000`.
6. Run `bun scripts/cli.ts deploy apply --env dev --service backend-core` and observe the returned job with `bun scripts/cli.ts job status <jobId> --tail-bytes 30000`.
7. Run `bun scripts/cli.ts deploy apply --env dev --service frontend` and observe the job the same way; this must consume the registry artifact and verify `/health.deploy.commit`.
7. Run `bun scripts/cli.ts deploy apply --env dev --service <frontend|decision-center|mdtodo|claudeqq|code-queue>` and observe the job the same way; this must consume the registry artifact and verify live deploy metadata through the service health path.
8. If the dev service catalog changes, deploy the pushed `k3sctl-adapter` commit through the controlled local manifest exception, then verify `/api/control-plane` lists `k3s/dev/unidesk-dev-core.k3s.json`.
9. Rebuild or verify `dev-frontend-proxy` on the main server with `bun scripts/cli.ts server rebuild dev-frontend-proxy` when the proxy config or port changes.
10. Manually test `http://74.48.78.17:18083/` and the dev health endpoints.
11. Run D601 CI for the commit and the dev smoke runner: `bun scripts/cli.ts ci run --revision <commit> --wait-ms <ms>` and `bun scripts/cli.ts ci run-dev-e2e --wait-ms <ms>`. When Code Queue behavior changes, update the `code-queue` entry in `environments.dev.services` to the pushed commit before running the dev smoke; do not use `deploy apply --env dev --service code-queue`.
11. Run D601 CI for the commit and the dev smoke runner: `bun scripts/cli.ts ci run --revision <commit> --wait-ms <ms>` and `bun scripts/cli.ts ci run-dev-e2e --wait-ms <ms>`. When Code Queue behavior changes, update the `code-queue` entry in `environments.dev.services` to the pushed commit before running dev artifact validation or the temporary dev smoke.
## Validation Commands
@@ -113,6 +114,8 @@ bun scripts/cli.ts server status
bun scripts/cli.ts deploy plan --env dev
bun scripts/cli.ts deploy plan --env dev --service backend-core
bun scripts/cli.ts dev-env validate --manifest src/components/microservices/k3sctl-adapter/k3s/dev/unidesk-dev-core.k8s.yaml
bun scripts/cli.ts dev-env validate --manifest src/components/microservices/k3sctl-adapter/k3s/dev/unidesk-dev-mdtodo.k8s.yaml
bun scripts/cli.ts dev-env validate --manifest src/components/microservices/k3sctl-adapter/k3s/dev/unidesk-dev-claudeqq.k8s.yaml
bun scripts/cli.ts dev-env validate --manifest src/components/microservices/k3sctl-adapter/k3s/dev/unidesk-dev-code-queue.k8s.yaml
bun scripts/cli.ts ci run-dev-e2e --wait-ms 600000
bun scripts/cli.ts microservice proxy k3sctl-adapter /api/services/backend-core-dev/proxy/health --raw --full