mirror of
https://github.com/trailofbits/buttercup
synced 2026-06-21 14:11:39 +00:00
2009c772b0
BUTTERCUP_PATCHER_TASK_STORAGE_DIR was /node_data/crs_scratch. The patcher's get_clean_task() resolves <task_storage>/<task_id>; under crs_scratch that path is already the fuzzer/scheduler per-task scratch dir (corpus/crashes/build subdirs, no task_meta.json). remote_archive_ to_dir() early-returns because the dir exists, so the pristine task is never materialized and TaskMeta.load() raises FileNotFoundError on task_meta.json during the patcher 'find_tests' node. Point it at /node_data/tasks_storage (same as BUTTERCUP_DOWNLOADER_DOWNLOAD_DIR / BUTTERCUP_SCHEDULER_TASKS_STORAGE_DIR), where the downloaded task with task_meta.json actually lives. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Docker Compose Development Setup
This directory contains the legacy Docker Compose setup for Buttercup CRS, preserved for developers who need to run specific components for quick testing and development.
Usage
From the repository root directory:
# Run all services
cd dev/docker-compose && docker-compose up -d
# Run specific services or profiles
cd dev/docker-compose && docker-compose --profile fuzzer-test up -d
cd dev/docker-compose && docker-compose --profile graphdb up -d
# Stop services
cd dev/docker-compose && docker-compose down
Using prebuilt images (skip local builds)
compose.prebuilt.yaml is an overlay that replaces every locally-built
component with its prebuilt image from GHCR, so nothing is built locally:
cd dev/docker-compose && docker compose -f compose.yaml -f compose.prebuilt.yaml up -d
# Pin a specific image tag (defaults to "main"):
BUTTERCUP_IMAGE_TAG=<branch-or-tag> docker compose -f compose.yaml -f compose.prebuilt.yaml up -d
Configuration
env.template- Template for environment variables (copy to.envand customize)env.dev.compose- Development-specific environment configurationcompose.yaml- Main compose file with all servicescompose.prebuilt.yaml- Overlay that pulls prebuilt GHCR images instead of building locally
Notes
- This setup is not recommended for production - use the Kubernetes deployment instead
- Primarily useful for developers who need to run individual components for testing
- The main deployment method is now Kubernetes via
make deployfrom the repository root - See the main README for the recommended setup instructions