test: add frontend artifact lane contract
This commit is contained in:
@@ -268,6 +268,14 @@ This matrix describes the next promotion stage after dry-run coverage is in plac
|
||||
| `k3sctl-adapter` | `master` | source-build supported | plan/dry-run only | no normal dev target; only control-bridge health and recovery evidence | prod live apply requires supervisor confirmation | bridge recovery, k3s fault-domain isolation, no worker self-replacement | `GPT-5.5` |
|
||||
| `filebrowser` / `filebrowser-d601` | `master` | upstream-image blocked | pull-only mirror target | digest resolution, mirror governance and private proxy health only | not in this phase | upstream digest/mirror worker not yet implemented | `DeepSeek` for evidence summarization, `GPT-5.5` for blocker resolution |
|
||||
|
||||
Frontend lane closure evidence is intentionally lightweight and non-mutating:
|
||||
|
||||
```bash
|
||||
bun scripts/frontend-artifact-lane-contract-test.ts
|
||||
```
|
||||
|
||||
The contract fixes the current sample around one artifact lane: `deploy.json` dev/prod both request the same frontend commit, `CI.json` keeps the producer as `ci publish-user-service`, the D601 registry manifest digest is recorded, dev and prod health expose matching `deploy.commit` / `deploy.requestedCommit`, `ci publish-user-service --dry-run` is ready, and both CD dry-runs are artifact consumers with no source build.
|
||||
|
||||
Planned parallelism for the next wave should be three lanes:
|
||||
|
||||
1. Lane A: `frontend`, `baidu-netdisk`, `project-manager`, `oa-event-flow`.
|
||||
|
||||
Reference in New Issue
Block a user