mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-08-28 05:27:41 +00:00
ed68c8b1d4
Rewrite every docs/ reference and integration guide example that previously showed legacy flat TOML (`[llm]`, `[vars]`, `[sandbox]`, `[setup]`, `[exec]`, `[fabro]`, `[pull_request]`, `[mcp_servers]`, `[git]`, `[web]`, `[api]`, `[features] retros`, `version = 1`, top-level `storage_dir`) to use the v2 namespaced schema. Also update the surrounding prose to describe v2 merge semantics (R22 run.inputs wholesale replacement, R71 sticky sandbox.env/labels, R30 whole-list prepare.steps replacement, hook id-based replacement). Files touched: - docs/reference/user-configuration.mdx (complete rewrite around [cli.*] ownership, [run.*] run-scoped defaults, [cli.target] / [cli.exec] / [cli.output] / [cli.updates] / [cli.logging], and [run.agent.mcps.<name>] with durations like "10s") - docs/reference/cli.mdx (settings.toml example uses [cli.exec.*], [run.model], [cli.target]) - docs/execution/run-configuration.mdx (full run-config example rewritten to use [workflow].graph, [run].goal/working_dir, [run.model], [run.prepare.steps], [run.sandbox.daytona.snapshot] with Size values, [run.inputs], [run.artifacts], [run.agent.mcps], [run.pull_request], [[run.hooks]] with optional id and duration timeout; section docs explain the new merge semantics) - docs/execution/environments.mdx and devcontainers.mdx (sandbox examples now use [run.sandbox.*]) - docs/execution/retros.mdx (retros moved to [run.execution] retros = true per R31) - docs/execution/failures.mdx (fallbacks now a single ordered array under [run.model].fallbacks) - docs/workflows/variables.mdx ([vars] → [run.inputs], wholesale replacement semantics explained) - docs/administration/server-configuration.mdx (full reference rewritten around [server.listen]/[server.api]/[server.web]/ [server.auth]/[server.storage]/[server.scheduler]/[server.logging]/ [server.integrations]) - docs/api-reference/overview.mdx (auth strategies now enabled via [server.auth.api.jwt].enabled and [server.auth.api.mtls].enabled; listener TLS moved to [server.listen.tls]) - docs/integrations/daytona.mdx, github.mdx (provider config now nested under [run.sandbox.daytona] / [server.integrations.github]) - docs/human-tools/ssh-access.mdx (sandbox examples to v2) - docs/agents/mcp.mdx (Playwright sandbox example to [run.agent.mcps]) - docs/core-concepts/models.mdx (model config and fallbacks array to [run.model]) Canonical fabro-cli overrides and server run_manifest now emit verbose via [cli.output].verbosity = verbose rather than the prior run.metadata staging. No code changes beyond those Stage 4 fixes that were already in flight.
45 lines
2.4 KiB
Text
45 lines
2.4 KiB
Text
---
|
|
title: "Devcontainers"
|
|
description: "Run Fabro workflows inside development containers"
|
|
---
|
|
|
|
Fabro can use your project's [devcontainer](https://containers.dev/) configuration to set up sandbox environments. When enabled, Fabro resolves `devcontainer.json` from the repository, uses its Dockerfile to build the Daytona sandbox snapshot, runs lifecycle hooks inside the sandbox, and merges devcontainer environment variables into the sandbox environment.
|
|
|
|
## Enabling devcontainer support
|
|
|
|
Set `devcontainer = true` in the `[run.sandbox]` section of your run config:
|
|
|
|
```toml title="run.toml"
|
|
_version = 1
|
|
|
|
[workflow]
|
|
graph = "workflow.fabro"
|
|
|
|
[run.sandbox]
|
|
provider = "daytona"
|
|
devcontainer = true
|
|
```
|
|
|
|
Fabro looks for `.devcontainer/devcontainer.json` in the repository root. If found, it extracts the Dockerfile, lifecycle commands, and environment variables from the configuration.
|
|
|
|
## What Fabro uses from devcontainer.json
|
|
|
|
| Field | How Fabro uses it |
|
|
|---|---|
|
|
| `build.dockerfile` | Used as the Dockerfile for the Daytona sandbox snapshot. A deterministic snapshot name is generated from a hash of the Dockerfile content. |
|
|
| `onCreateCommand` | Runs inside the sandbox after it's created |
|
|
| `postCreateCommand` | Runs after `onCreateCommand` completes |
|
|
| `postStartCommand` | Runs after the sandbox starts |
|
|
| `containerEnv` | Merged into sandbox environment variables (TOML `[sandbox.env]` values take precedence on key collisions) |
|
|
|
|
Lifecycle commands (`onCreateCommand`, `postCreateCommand`, `postStartCommand`) execute sequentially inside the sandbox. If any command fails, the run aborts before the workflow starts.
|
|
|
|
## Dockerfile limitations
|
|
|
|
Fabro detects and reports unsupported `COPY` and `ADD` instructions in devcontainer base Dockerfiles. These instructions reference files from the build context, which isn't available when building Daytona snapshots. If your Dockerfile uses `COPY` or `ADD`, you'll need to restructure it to use `RUN` commands that fetch files at build time (e.g., via `curl` or `wget`).
|
|
|
|
## Interaction with other sandbox settings
|
|
|
|
When `devcontainer = true`, the devcontainer Dockerfile overrides any `snapshot.dockerfile` setting in `[sandbox.daytona]`. Other Daytona settings (`cpu`, `memory`, `disk`, `auto_stop_interval`, `labels`) still apply.
|
|
|
|
Environment variables from `containerEnv` in the devcontainer config are merged with `[sandbox.env]` from the TOML config. On key collisions, the TOML config wins.
|