magus v0.4.3 is out. See what's new
¶ View generated markdown
5 min read

magus-affected

Run a target for VCS-diff affected projects

Synopsis

magus affected <target> [flags]

Description

Run a named target for every project that is affected by changes in version control. The active VCS adapter is picked by autodetect from .git, .hg, or .jj at the workspace root, or pinned with MAGUS_VCS_NAME / vcs.name. When MAGUS_VCS_ENABLED=false (or vcs.enabled: false) affected detection short-circuits and falls back to the full project set with the source label "vcs disabled".

A project is affected if any of its source files changed directly, or if a project it depends on is affected (transitive closure over the dependency graph).

Use --stdin to read changed paths from a pipe instead of running a VCS diff. This pairs with magus watch for continuous-build workflows:

magus watch | magus affected --stdin build

Forensic modes reason about the affected set instead of executing a target. --explain shows why a project is in the set. --plan emits a provider-neutral JSON shard plan for the named target. Combine --plan with --stdin for a one-shot plan of proposed paths before editing. --bisect drives VCS bisect using run history to find the commit that introduced a regression.

magus affected ci sizes its gate to the change. Each changed path gets a risk tier (trivial, mechanical, scoped, full) and the change takes the highest. Below full, the gate runs only what the tier needs (the drift check and lint, the targets that declare a changed doc, or the project's test with go-test narrowed to the packages that can observe the change) and prints every path with its tier to stderr; a trivial change runs nothing and exits 0. With --plan, a trivial change emits an empty matrix beside a risk block. --no-redundancy-check runs the full gate.

--plan downstream of magus in a pipe waits for every magus stage before it to end, and prints no plan if one failed (MGS3030). CI gates its shards on drift that way: magus affected generate --no-default-charms | magus affected ci --plan.

Options

-b string
Short for --base
--base string
Override base ref for the VCS diff (default: MAGUS_VCS_BASE_REF or per-VCS built-in)
--bisect string
Drive VCS bisect to find the commit that broke <project>
--depth int
With --graph: cap displayed depth (0 = unlimited)
--detach
Run in the background as its own session, writing to a log under $XDG_STATE_HOME/magus/detached/; prints the pid and the log path and returns. Needs no server
--detail
With --plan: add per-shard detail - the invocation, its spells, the files it declares it writes, and the skills its work routes to
--explain string
Show why <project> is in the affected set instead of executing
--good string
With --bisect: known-good commit SHA (auto-detected from history when empty)
--graph
Render the dependency graph for the affected scope instead of executing
--impact
Report the blast radius of the changeset (read-only; runs nothing)
--max-parallel-budget int
With --plan: cross-shard concurrency cap; 0 = unlimited
--max-shards int (default: 8)
With --plan: maximum CI shards (-1 = unlimited)
--no-cache
Force a fresh run even on a cache hit; still refreshes the entry
--no-default-charms
Ignore magus.yaml default_charms for this run
--no-redundancy-check
Run the full ci gate: no deferral and no tier reduction (MGS3010); ci target only
--null
With --stdin: expect NUL-separated paths and double-NUL between batches
--open
Open this run in the browser log viewer and stream to it as it goes (loopback; never leaves your machine)
--plan string
Emit a provider-neutral JSON CI shard plan for the affected set
--race string
Race-condition diagnostics (watch|replay, comma-combinable); omit to disable. watch: attribution-gated fsnotify detection (MGS4001/4002/4004), emitting only when >=2 projects' output snapshots confirm a shared write. replay: re-runs cacheable output-declaring projects sequentially to content-hash outputs for non-determinism (MGS4003); roughly doubles wall-clock.
--stdin
Read changed file paths from stdin instead of running a VCS diff
--step
Pause before each subprocess for interactive stepping (needs a TTY; implies --concurrency=1)
--target string (default: test)
With --bisect: magus target to bisect
--timeout duration
Abort if the run has not finished within this duration (e.g. 5m, 1h30m)
--upstream
With --graph: show dependents instead of dependencies

Targets

ls
Print selected projects without executing anything
build
Build selected projects
test
Test selected projects
lint
Lint selected projects (read-only)
format
Format source files in selected projects
clean
Remove declared outputs from selected projects
generate
Run code generation for selected projects
ci
Run the magusfile's ci target read-only (affected-set anchor)

Exit status

0
Every affected project's target succeeded. An empty affected set is also 0: nothing changed is a pass, not a fault, so a CI job gating on this stays green on a docs-only commit.
1
At least one target failed, already reported with the path to its captured log.
2
Misuse: no target named, or --step without an interactive terminal.
75
Nothing ran, and trying again later would succeed; 75 is EX_TEMPFAIL, the transient-failure convention. A selected project's workspace lock or the machine's build budget was held by another magus invocation (magus never queues behind one; the error names the holder's pid, command and directory), or a ci gate was deferred as redundant under load (MGS3010; the error names the green gate it found and --no-redundancy-check overrides).

Examples

Build projects changed since the default base ref

magus affected build

Use a different base ref

magus affected build --base main

Pipe from watch for continuous builds

magus watch | magus affected --stdin build

List affected projects without building

magus affected list

Show dependency graph for the affected scope

magus affected build --graph

Graph as DOT for piping to Graphviz

magus affected build --graph -o dot | dot -Tsvg > graph.svg

Emit a CI shard plan for the affected set

magus affected ci --plan

Gate a CI shard plan on drift: no plan, and no shards, unless generate passes

magus affected generate --no-default-charms | magus affected ci --plan

Shard a test plan across at most four workers

magus affected test --plan --max-shards 4

Bisect a regression in myapp

magus affected --bisect ./apps/myapp

See Also

magus(1), magus-ls(1), magus-describe(1), magus-run(1), magus-x(1), magus-where(1), magus-graph(1), magus-query(1), magus-explain(1), magus-path(1), magus-refs(1), magus-watch(1), magus-events(1), magus-status(1), magus-clean(1), magus-shell(1), magus-vcs(1), magus-queue(1), magus-doctor(1), magus-config(1), magus-session(1), magus-job(1), magus-notes(1), magus-diff(1), magus-server(1), magus-broker(1), magus-mcp(1), magus-buzz(1), magus-completion(1), magus-man(1), magus-init(1), magus-spell(1), magus-agent(1), magus-self(1), magus-version(1)

ManpagePages in this section. magus runRun a named target (build, test, lint, format, ci, etc.) for the selected projects, defaulting to the cwd project when no arguments are given. SpellsA spell is a library of tool-native ops (go-build, cargo-clippy, eslint) plus cache metadata that your magusfile composes into runnable targets. ChangelogEvery change to magus, newest first, in Keep a Changelog format, starting with the unreleased entries. Generated from changes/unreleased/ and releases/*.yaml.
generatedinternal/cli/registry.goclimagus affectedaffectedchanged filesvcsgitbisectci
Last updated (aba0c4fa)
Earlier changes on this page (7)

Full history ↗ · Blame source ↗

Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. See workspace.

Project

A directory magus recognizes as a unit of work (it has a magusfile); the unit of caching, scheduling, and dependency tracking. See workspace.

Magusfile

The magusfile.buzz that declares a project's targets (as export funs) and binds its spells. See targets.

Target

A named operation (build, test, ...) you invoke with magus run <target>; it may compose a spell's tool-native operations and depend on other targets. See targets.

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). See operations.

Spell

A language/runtime adapter (e.g. go, md) that maps generic targets onto a toolchain's real commands. See spells.

Charm

An execution modifier attached with : (lint:rw) that changes how a target runs, not which one; the built-in rw flips a check-only target to mutate in place, and ci always strips it. See charms.

Buzz

The language magusfiles are written in (the .buzz engine). See engines.

Cache

The content-addressed store magus consults before running a target, so unchanged work is skipped. See cache.

Affected

The set of projects touched by a change; magus affected <target> runs a target only over them. See affected.

Broker

The per-user background process that holds this host's capacity: the machine budget every run claims slots from, and the shared services runs keep warm. A run starts it on demand; broker: off in magus.yaml runs without one. See server.

Server

The background process a person starts with magus server start. It serves MCP, the console, background jobs and the warm knowledge graph, and adopts nested magus calls into one pool. See server.

CI

An ordinary magusfile-defined target you compose yourself with magus\needs: magus does not hardcode its stages. Magus.RunCI treats it specially only in that it strips the rw charm, it is the anchor magus affected ci keys off, and a selected scope with no project declaring it is a load error rather than a silent no-op. See targets.

Concurrency

How many targets run at once. It is bounded by the pool's capacity and set with --concurrency, MAGUS_CONCURRENCY, or the concurrency config key. See server.

Snapshot

A point-in-time view of live state (the pool's occupancy or a tick of exported metrics), as opposed to accumulated history. See server.

MAGUS.md

The committed routing index at a workspace root, regenerated from the knowledge graph: it lists every node and points at the exact query for a given question, so it is the entry point an agent reads first. See knowledge.

Session

An agent host's conversation, by the id the host delivers to its hooks. magus never mints one: a record with no session is unattributed, and the OS user it carries says whose account ran it.

Invocation

One magus process's recorded facts (the targets it finished, their outcomes, the lease it acted as, and the session it ran in when a host delivered one), kept in a repo-scoped store every worktree shares. magus session lists them; the store prunes itself by last-fact age.

Job

The unit of delegated work, and one row of the job store: what an orchestrating agent handed out, with its goal, the checkpoint it was cut against, the paths it may write or must not touch, and the one check it runs. A job's holder is either a session, for work an orchestrator handed out, or the server, for its own maintenance. The store records; the agent guard is what reads those facts back when grading a write. See doctrine.

A job is not a run. magus run build web is a run, and no job exists for it. A job causes runs: its check executes as one, and a server job records the invocation of its last one. Jobs are listed with magus ls jobs and in the console's Jobs view; runs are listed in the Runs view.

Run

One target executing under one magus invocation, such as magus run test web or magus affected ci. A run keeps its captured output behind an output reference. Every magus run is a run whether or not any job asked for it; see Job for how the two relate.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.