mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-08-28 05:27:41 +00:00
157ec03a18
Reflect Docker as the default sandbox provider, add `skip_clone` for clone-based providers, document the `[run.sandbox.docker]` config table, and update tutorial command lines from `files-internal/...` to `docs/internal/...`. Bump the docs skill watermark to the latest synced commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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 `[run.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 `[run.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 `[run.sandbox.env]` from the TOML config. On key collisions, the TOML config wins.
|