Skip to main content

engine-lab

Build and debug the Dagger engine from the workspace source with the EngineLab tools — the sandbox equivalent of the ./hack/dev + ./hack/with-dev loop. Read before using the engine-lab tools to run commands against a live from-source engine, poke its debug/pprof endpoints, run engine tests, or re-run repros after editing engine code.

跳到安装

来源信息

仓库
dagger/dagger
最近来源活动
2026年9月17日 22:38
检测到的 SKILL.md 语言
英语
星标
16,289
分支
924

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
engine-lab
description
Build and debug the Dagger engine from the workspace source with the EngineLab tools — the sandbox equivalent of the ./hack/dev + ./hack/with-dev loop. Read before using the engine-lab tools to run commands against a live from-source engine, poke its debug/pprof endpoints, run engine tests, or re-run repros after editing engine code.
# Engine Lab You can build and debug the Dagger engine from the workspace source with the EngineLab tools — the sandbox equivalent of the `./hack/dev` + `./hack/with-dev` loop from the `engine-debugging` skill. Workflow: - the engine-lab start tool builds the engine + CLI from the workspace source and runs the engine as a persistent service with its debug endpoints enabled. The first build takes a while; later tools reuse the running engine. - `dagger(args: [...])` runs `dagger <args>` against the live engine — pass the subcommand WITHOUT a leading "dagger" (e.g. `["call", "test"]`). The from-source CLI is on PATH and your CURRENT workspace tree is mounted at /src, re-mounted fresh on every call so your edits are always visible — only the engine *binary* is pinned until `restart`. Commands that talk to Dagger Cloud run authenticated when the module's `cloudCredentials` setting is configured in dagger.toml (`cloudCredentials = "file://~/.config/dagger/credentials.json"`, mounted where the CLI's auth code looks); without it the CLI runs logged out. - `query` sends raw GraphQL straight to the engine (no module loaded). - `debugGet`/`debugJq` hit the engine's :6060 debug endpoints (routes in cmd/engine/debug.go), e.g. /debug/pprof/goroutine?debug=2 for hangs; use debugJq to filter big JSON like /debug/dagql/cache. - After editing engine code, `restart` rebuilds and replaces the running engine; then re-run your repro with `dagger`. - `engineTest(pkg, run)` runs engine tests with their own ephemeral engine (no `start` needed), e.g. pkg "./core/integration" with run "TestSuite/TestSub". - `dumpId(file, ...)` builds and runs the repo's own `cmd/dump-id` against a file in your workspace — no engine session needed. `file` is a workspace-relative path to a base64 call ID. Modes mirror the command's flags: `stats` (per-field counts, chain depth, expansion/re-execution counts — the mode for "why did this recipe run that call N times?"), `tree`, `jsonOutput`, `find` (regexp over Type.field names), `diff` (structural diff against a second recipe file), plus `lit`/`spine`/`depth` for verbosity and `limit` to cap the returned lines. The binary is rebuilt from your current tree, so edits to cmd/dump-id take effect immediately. - Engine logs: ListServices shows the engine service's span ids; ReadLogs(span, grep, limit) reads them — the equivalent of `docker logs dagger-engine.dev | grep`. - the engine-lab start tool prints the engine's tcp://<host>:1234 endpoint (`endpoint` re-prints it). If tui-qa tools are available, pass it to their start tool's `engineAddress` arg to run a TUI session against THIS engine — then `debugGet`/`debugJq`/ReadLogs introspect the very engine the TUI is driving (e.g. reproduce a hang in the TUI, then pprof it live). `restart` and the engine-lab stop tool break attached TUI sessions; restart them after. - the engine-lab stop tool when done.
在 GitHub 查看