Skip to main content

​
Overview

The PipelineConfig struct controls how Magpie executes tasks: repository location, base branch, test and lint commands, CI retry limits, and integration settings.

​
Configuration Structure

pub struct PipelineConfig {
    pub repo_dir: PathBuf,
    pub base_branch: String,
    pub test_command: String,
    pub lint_command: String,
    pub max_ci_rounds: u32,
    pub plane: Option<PlaneConfig>,
    pub dry_run: bool,
    pub github_org: Option<String>,
    pub trace_dir: Option<PathBuf>,
    pub daytona: Option<DaytonaConfig>,
    pub pool: Option<Arc<WarmPool>>,
}
Source: crates/magpie-core/src/pipeline.rs:26-48

​
Basic Settings

​
repo_dir
PathBuf
default:"."
Path to the git repository to operate on. When github_org is set, this is ignored in favor of dynamic repo resolution.Environment Variable: MAGPIE_REPO_DIRExample:
MAGPIE_REPO_DIR=/home/user/my-project
​
base_branch
String
default:"main"
Base branch for new feature branches. All Magpie branches are created from this branch and PRs target it.Environment Variable: MAGPIE_BASE_BRANCHExample:
MAGPIE_BASE_BRANCH=develop
​
test_command
String
default:"cargo test"
Command to run tests during the CI loop. Executed after the agent completes its work.Environment Variable: MAGPIE_TEST_CMDExamples:
MAGPIE_TEST_CMD="cargo test"
MAGPIE_TEST_CMD="npm test"
MAGPIE_TEST_CMD="pytest tests/"
​
lint_command
String
default:"cargo clippy"
Command to run lints during the CI loop. Executed before tests.Environment Variable: MAGPIE_LINT_CMDExamples:
MAGPIE_LINT_CMD="cargo clippy"
MAGPIE_LINT_CMD="npm run lint"
MAGPIE_LINT_CMD="ruff check ."
​
max_ci_rounds
u32
default:"2"
Maximum number of lint→test→fix retry attempts. If CI fails after this many rounds, the pipeline returns PartialSuccess status.Environment Variable: MAGPIE_MAX_CI_ROUNDSExample:
MAGPIE_MAX_CI_ROUNDS=3
Note: For Standard and BugFix tasks, the blueprint already runs tests+lint internally. If those pass, the first CI round is skipped (effectively starting at round 2).

​
Multi-Repo Support

​
github_org
Option<String>
default:"None"
GitHub organization to restrict repo access to. When set, Magpie dynamically resolves the target repo from the task message.Environment Variable: MAGPIE_GITHUB_ORGBehavior:
  • Parses repo name from patterns like "fix bug in api-service" or "deploy repo api-service"
  • Validates the repo belongs to the configured org (rejects cross-org references)
  • Clones the repo into a temp workspace using gh repo clone
  • Temp directory is automatically cleaned up when the pipeline completes
Example:
MAGPIE_GITHUB_ORG=my-company
Use Case: Run a single Magpie instance across multiple repos in the same GitHub organization.Source: crates/magpie-core/src/pipeline.rs:754-790

​
Advanced Options

​
plane
Option<PlaneConfig>
default:"None"
Optional Plane issue tracking integration. When set, Magpie creates issues at pipeline start and updates them on completion.See Plane Configuration for details.
​
dry_run
bool
default:"false"
When true, agent steps are replaced with shell echo stubs (for testing). Git operations still run, but no actual code changes are made.Use Case: Testing pipeline orchestration without invoking the LLM.
​
trace_dir
Option<PathBuf>
default:"None"
Directory for JSONL trace files. When set, all agent calls (Tier 1 and Tier 2) are recorded with timestamps, tool calls, and response metadata.File Format: .magpie/traces/magpie-trace-YYYY-MM-DD.jsonlExample:
MAGPIE_TRACE_DIR=.magpie/traces
Use Case: Debugging agent behavior, auditing LLM usage, and analyzing pipeline performance.
​
daytona
Option<DaytonaConfig>
default:"None"
When set, pipeline runs execute inside a Daytona sandbox. If None, commands execute locally.See Sandbox Configuration for details.
​
pool
Option<Arc<WarmPool>>
default:"None"
Warm sandbox pool. When set, the pipeline tries to acquire a pre-built sandbox before falling back to cold creation.Feature Flag: Requires daytona feature.See Sandbox Configuration for details.

​
Default Configuration

The default configuration is suitable for Rust projects using Cargo: 
PipelineConfig {
    repo_dir: PathBuf::from("."),
    base_branch: "main".to_string(),
    test_command: "cargo test".to_string(),
    lint_command: "cargo clippy".to_string(),
    max_ci_rounds: 2,
    plane: None,
    dry_run: false,
    github_org: None,
    trace_dir: None,
    daytona: None,
    pool: None,
}
Source: crates/magpie-core/src/pipeline.rs:50-67

​
Pipeline Result

Every pipeline run returns a structured PipelineResult: 
pub struct PipelineResult {
    pub output: String,
    pub pr_url: Option<String>,
    pub plane_issue_id: Option<String>,
    pub ci_passed: bool,
    pub rounds_used: u32,
    pub status: PipelineStatus,
}

​
Status Values

​
Success
PipelineStatus
Agent completed the task and all CI checks passed.
​
PartialSuccess
PipelineStatus
Agent completed the task and opened a PR, but CI checks failed after max_ci_rounds attempts.
​
AgentFailed
PipelineStatus
The agent encountered an error during blueprint execution.
​
SetupFailed
PipelineStatus
Pipeline setup failed (git branch creation, sandbox creation, or repo validation).
Source: crates/magpie-core/src/pipeline.rs:70-87

​
Example Configurations

​
Rust Project (Default)

MAGPIE_REPO_DIR=.
MAGPIE_BASE_BRANCH=main
MAGPIE_TEST_CMD="cargo test"
MAGPIE_LINT_CMD="cargo clippy"
MAGPIE_MAX_CI_ROUNDS=2

​
Node.js Project

MAGPIE_REPO_DIR=/home/user/my-app
MAGPIE_BASE_BRANCH=develop
MAGPIE_TEST_CMD="npm test"
MAGPIE_LINT_CMD="npm run lint"
MAGPIE_MAX_CI_ROUNDS=3

​
Python Project

MAGPIE_REPO_DIR=/workspace/api-service
MAGPIE_BASE_BRANCH=main
MAGPIE_TEST_CMD="pytest tests/"
MAGPIE_LINT_CMD="ruff check . && mypy ."
MAGPIE_MAX_CI_ROUNDS=2

​
Multi-Repo Setup

MAGPIE_GITHUB_ORG=my-company
MAGPIE_BASE_BRANCH=main
MAGPIE_TEST_CMD="cargo test"
MAGPIE_LINT_CMD="cargo clippy"
Note: When MAGPIE_GITHUB_ORG is set, MAGPIE_REPO_DIR is ignored. Magpie parses the repo name from the task message and clones it dynamically.

​
CI Classification

Magpie automatically classifies changed files to determine whether to run CI: Docs-only extensions:
  • .md, .txt, .rst, .adoc
  • .png, .jpg, .gif, .svg, .ico
  • .json, .yml, .yaml
Docs-only filenames:
  • LICENSE, CHANGELOG, CHANGES, AUTHORS, CONTRIBUTORS
Behavior:
  • If all changed files are docs-only → skip CI
  • Otherwise → run lint + test loop
  • For Standard/BugFix tasks, if the blueprint’s built-in test+lint steps already passed, the CI loop is skipped entirely
Source: crates/magpie-core/src/pipeline.rs:1057-1160

Build docs developers (and LLMs) love

Get started for freeTalk to us