@kubb/studio 5.3.16 → 5.3.18
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +29 -7
- package/dist/index.cjs +695 -542
- package/dist/index.cjs.map +1 -1
- package/dist/index.d.ts +68 -33
- package/dist/index.js +693 -543
- package/dist/index.js.map +1 -1
- package/dist/protocol.cjs +20 -0
- package/dist/protocol.cjs.map +1 -1
- package/dist/protocol.d.ts +77 -40
- package/dist/protocol.js +19 -1
- package/dist/protocol.js.map +1 -1
- package/package.json +4 -4
package/README.md
CHANGED
|
@@ -68,6 +68,14 @@ The runtime discovers nothing on its own: the host injects the config loader, th
|
|
|
68
68
|
own version. That is what lets one runtime serve a CLI running in a developer's project and a
|
|
69
69
|
container running a fixed plugin set.
|
|
70
70
|
|
|
71
|
+
## Package layers
|
|
72
|
+
|
|
73
|
+
`src/protocol` defines the shared wire contracts and imports no Studio implementation. `src/operations`
|
|
74
|
+
contains focused work such as pairing, generation, config edits, snapshots, and transport; it may
|
|
75
|
+
import the protocol. `src/runtime` owns connection state and coordinates operations; it may import
|
|
76
|
+
both lower layers. Keep new code in the lowest layer that can own it, with direct internal imports.
|
|
77
|
+
Only `@kubb/studio` and `@kubb/studio/protocol` are public entry points.
|
|
78
|
+
|
|
71
79
|
## Hosts and the runtime
|
|
72
80
|
|
|
73
81
|
Three hosts run this package: `kubb studio`, the `kubblabs/kubb-agent` Docker image, and
|
|
@@ -109,14 +117,19 @@ the machine-facing surface, singular because the caller is describing itself. Th
|
|
|
109
117
|
`/api/agents` is the collection a signed-in user manages in the browser, and the runtime never
|
|
110
118
|
touches it.
|
|
111
119
|
|
|
112
|
-
| Step
|
|
113
|
-
|
|
|
114
|
-
| Register
|
|
115
|
-
|
|
|
116
|
-
|
|
117
|
-
|
|
120
|
+
| Step | Call | What it does |
|
|
121
|
+
| -------- | --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
|
|
122
|
+
| Register | `POST /api/agent/connect` | Binds the token to this machine and process (`machineToken`, `instanceId`), reports `capacity`, and returns `socketUrl` |
|
|
123
|
+
| Connect | Configured RPC connector on `socketUrl` | Opens the process's one socket with the bearer token and `x-kubb-instance-id`, then attaches the typed `AgentApi`/`StudioApi` RPC session |
|
|
124
|
+
|
|
125
|
+
Every connection attempt registers first, so a reconnect is also how the agent registers again.
|
|
126
|
+
Each heartbeat carries the agent's load. A process keeps one socket, not one per job: Studio
|
|
127
|
+
schedules jobs onto it up to the advertised `maxConcurrent`. Studio's close codes say whether to
|
|
128
|
+
come back: `4001` registers and reconnects, `4002` (another instance took over) and `4003` (the
|
|
129
|
+
agent is too old or was deleted) stay down. A `426` at registration means the agent is too old for
|
|
130
|
+
that Studio.
|
|
118
131
|
|
|
119
|
-
The runtime reconnects on its own when
|
|
132
|
+
The runtime reconnects on its own when the socket drops, and keeps retrying while Studio is
|
|
120
133
|
unreachable. Generation progress is a native Cap'n Web `ReadableStream` on the generation
|
|
121
134
|
capability; durable job status is read through the HTTP job API.
|
|
122
135
|
|
|
@@ -197,6 +210,15 @@ Pass `commit` with a snapshot job, and the finished snapshot carries `changes`:
|
|
|
197
210
|
changed, and removed since the previous snapshot of the same package on the same agent, and which
|
|
198
211
|
snapshot (and commit) that was. `base` is `null` on the first one.
|
|
199
212
|
|
|
213
|
+
Pass `baseId` (the `id` another CI agent's runs register under) and the snapshot also carries
|
|
214
|
+
`branchChanges`: the same comparison against that agent's latest snapshot. On a GitHub pull
|
|
215
|
+
request or a GitLab merge request, `kubb studio snapshot` passes the agent its base branch's runs
|
|
216
|
+
use. Elsewhere, pass `--base-id` with the `--id` those runs use.
|
|
217
|
+
|
|
218
|
+
Runs that share an agent (one pull request, or one branch) must not overlap, since registering it
|
|
219
|
+
again ends the other run's session. Serialize them per ref, such as a GitHub Actions `concurrency`
|
|
220
|
+
group on `github.ref` or a GitLab `resource_group` on `$CI_COMMIT_REF_SLUG`.
|
|
221
|
+
|
|
200
222
|
A snapshot job packs the tarball on the agent, not on Studio. The agent `PUT`s an empty request to
|
|
201
223
|
a path Studio provides, gets back a redirect to a short-lived storage URL, and uploads the tarball
|
|
202
224
|
there. The storage URL never crosses the RPC socket.
|