Repository navigation
Step Context
Lua step callbacks receive one argument: the step context table, conventionally named ctx.
step({
name = "lint",
phase = "qa",
scope = "default",
run = function(ctx)
return 0
end,
})Only available inside Lua run callbacks. Shell steps do not get ctx.
| Member | Type | Description |
|---|---|---|
project_root |
string | Absolute path to project root |
Returns the merged step config table, or nil if none.
local config = ctx.get_config()
local patterns = config.patternsSee Configure Step.
Expand glob patterns relative to project_root.
local files = ctx.glob({ "src/**/*.cpp", "include/**/*.hpp" })| Argument | Type | Description |
|---|---|---|
patterns |
string array | Glob patterns (same syntax as step input/output) |
Returns a 1-based Lua array of relative file paths (sorted). Empty if nothing matches.
Uses the glob metadata cache when enabled in performance settings.
Run shell commands in parallel from a Lua callback. Use colon syntax (:) for these methods.
Start a background worker.
local job = ctx:spawn({
name = "lint-file",
cmd = "clang-tidy " .. file,
inputs = { file },
outputs = { file .. ".linted" },
})| Field | Required | Type | Description |
|---|---|---|---|
name |
yes | string | Worker label (logs) |
cmd |
yes | string or string array | Shell command(s) run sequentially in the worker |
inputs |
no | string array | Input paths for worker cache key |
outputs |
no | string array | Output paths for worker cache key |
Returns a worker handle (integer id).
Wait for one worker. Returns shell exit code.
local code = ctx:wait(job)
if code ~= 0 then
return code
endOn success, records worker duration for cache_file_success().
Wait for multiple workers. Returns 0 if all succeeded, otherwise the first non-zero exit code.
local jobs = {}
for _, file in ipairs(files) do
jobs[#jobs + 1] = ctx:spawn({ name = file, cmd = "lint " .. file })
end
return ctx:wait_all(jobs)| Argument | Behavior |
|---|---|
| Table of handles | Wait for those workers |
nil or empty table |
Drain all pending workers in the pool |
Workers require the worker pool (available during Lua step execution). If unavailable, spawn throws worker pool is not available in this step context.
Per-file or per-key incremental cache inside a Lua callback. Stored under .cache/success/. Disabled when --no-cache or cache.enabled = false.
Returns true if relative file path path was previously cached as successful.
if ctx.file_success_cached(source_path) then
skipped = skipped + 1
else
-- run tool on source_path
endMark path as successfully processed. Uses pending worker duration from the last ctx:wait() when applicable.
ctx.cache_file_success(source_path)Generic string key success check (not file-based).
Mark generic key as successful.
Record that path failed, so the next run re-checks it even if other files are cached.
Record generic key miss.
Returns a 1-based array of paths/keys that failed in the previous run (for incremental re-check).
local misses = ctx.get_cache_misses()
for _, entry in ipairs(misses) do
print("re-checking: " .. entry)
endBump a revision field in configure_step() when the tool or rules change without source file changes.
| Call style | Functions |
|---|---|
Dot (ctx.glob) |
glob, get_config, success cache helpers |
Colon (ctx:spawn) |
spawn, wait, wait_all
|
run = function(ctx)
local files = ctx.glob({ "src/**/*.cpp" })
local jobs = {}
for _, file in ipairs(files) do
jobs[#jobs + 1] = ctx:spawn({
name = "compile-" .. file,
cmd = "g++ -c " .. file,
inputs = { file },
outputs = { file .. ".o" },
})
end
return ctx:wait_all(jobs)
end- DSL Patterns - incremental per-file lint/format
- Caching - step cache vs success cache
- Step Declaration - artifact patterns on steps
Quick Reference · Glossary · FAQ
- Fundamentals
- Core Concepts
- Project Layout
- First Pipeline
- Phases and Scopes
- How Phases and Scopes Work
- Selecting with Phases and Scopes
- Designing Phases and Scopes
- Parallel Execution and Dependencies
- Configuration
- Configuration Overview
- Global User Config
- Project Config
- Environment Variables
- Performance Settings
- Cache Settings
- Config Reference
- CLI
- CLI Overview
- Running Targets
- Filtering by Phase
- Running a Single Step
- Listing Entities
- Output and Logging Flags
- Cache and Maintenance Flags
- Meta and Utility Commands
-
Project Scaffolding —
beez --init(embedded Tempify) - CLI Flag Reference
- Lua DSL
- DSL Overview
- Plugin System — Plugins, Config DSL, Standard-Workflows
- Step Declaration
- Task Declaration
- Workflow Declaration
- Order Declaration
- Configure Step
- ReqPack Declaration
- Beez API
- Step Context
- DSL Patterns
- Caching
- Caching Overview
- Step Cache
- Success Cache
- Glob Metadata Cache
- Artifact Patterns
- Cache Keys and Invalidation
- Cache Storage and Maintenance
- Caching Troubleshooting
- UI and Output
- Output Modes
- Progress and Animation
- Colors and Themes
- Run Summaries
- Logging and Log Files
- Development and Contribution
- Building and Setup
- Repository Layout
- Testing
- Code Quality
- Feature Development Workflow
- Submitting Changes