magus v0.4.3 is out. See what's new
¶ View markdown source · ✎ Suggest an edit
2 min read

worker-check-only

A deny rule by default: it refuses a bound worker running a target other than its row's check or one writing its write paths, and names what to run instead.

What it catches

A bound worker running a target other than its row's check or one writing its write paths.

Why

A worker's row names one check, and the orchestrator runs every other target serially, in its own tree, after the units land. Two workers running the same target at once from two worktrees double the load and prove nothing the orchestrator's one run does not: the cache replays a run that has landed and never two in flight, and two trees share no key. Allowed under a live lease: the row's check, with or without a charm and forwarded args; a magus run of a target that declares an output among the row's write paths, read from the workspace's own declarations (a -generate name or a charm stands in when the workspace cannot load); magus's own go-build . in its own checkout; and every other verb, and every run that only reports (--plan, --dry-run, --graph). magus affected is never the check, since it takes its projects from the diff. An unbound caller, a row that owns the gate and a row declaring no check are untouched. The same rule grades a spawn or continuation brief naming a live row (by magus.lease=, job exec or its JOB ID line): a brief telling that worker to run another target is refused under brief-command, quoting the line, before any worker exists.

Default and override

By default this rule takes the decision deny. A workspace sets it by name, in its root magusfile, to deny, advise or off:

magus\guard.builtins({"worker-check-only": "advise"})

A loosening takes effect once it is committed; a tightening applies at once.

Seeing it

A verdict names its rule in brackets, which is how you got here:

deny [worker-check-only]: ...

magus describe rule worker-check-only prints the same entry at a terminal, and magus describe rules lists every rule this workspace enforces.

See also

ReferencePages in this section. magus documentationThe magus documentation hub covering install, targets, spells, charms, operations, engines, remote caching, MCP, telemetry, and the interactive playground. magus-runRun builds, tests, lints, and codegen through magus targets. SpellsA spell is a library of tool-native ops (go-build, cargo-clippy, eslint) plus cache metadata that your magusfile composes into runnable targets.
guardrulesworker-check-onlydeny
Last updated (1a76274f)
Earlier changes on this page (1)

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.

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.

Ward

A coded diagnostic that inspects a resolved op and nudges or blocks an anti-pattern before it runs. See wards.

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.

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.

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.

Lease

The grant a holder takes on a job: the write and read paths that job declared, enforced in the checkout that took it with magus job exec. A job is the piece of work; a lease is permission over it.

Conventions

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