-
Notifications
You must be signed in to change notification settings - Fork 0
Configure Step
Attach structured configuration to a step without hard-coding values in the callback.
Plugins: use
configure({ { "coditary/plugin", { ... } } })inbuild.luaand the Plugin Config DSL (defaults,profile_defs,finalize) inbeez_plugin.lua. See Plugin System.
configure({
{ "coditary/cppcheck", {
check_rev = "2",
steps = {
cppcheck_check = { profiles = { "analyze", "security" } },
},
}},
{ ":my_local_step", { flag = true } }, -- leading ':' = standalone step
})Configure one plugin by qualified name (organization/plugin).
configure_step("lint", {
patterns = { "src/**/*.cpp" },
lint_rev = "1",
})
step({
name = "lint",
phase = "qa",
scope = "default",
run = function(ctx)
local config = ctx.get_config()
local files = ctx.glob(config.patterns)
-- ...
return 0
end,
})| Argument | Type | Description |
|---|---|---|
name |
string | Step name (must match step({ name = ... })) |
config |
table | Arbitrary Lua table |
configure_step() can appear before the step() declaration. Beez stores pending config and merges it when the step registers.
configure_step("shader", { shader_version = "450" })
step({
name = "shader",
phase = "generate",
scope = "code",
config = { output_dir = "build/shaders" },
run = "echo shader",
})step({
name = "lint",
phase = "qa",
scope = "default",
config = { patterns = { "src/**/*.cpp" } },
run = function(ctx) ... end,
})Inline config and configure_step() merge. Later configure_step() calls merge on top of earlier config for the same step name.
Tasks can pass config when invoking a step:
task("lint-strict", {
{ name = "lint", config = { warnings_as_errors = true } },
})Merge order (lowest to highest priority):
- Inline
step({ config = ... }) -
configure_step()(later calls override earlier ones for the same step) - Task invocation
{ config = ... }
local config = ctx.get_config()
if config == nil then
return 1
endReturns nil if the step has no config.
Step config participates in step cache keys. The config table is serialized to a fingerprint string. Changing config invalidates cached results for that step.
Use revision keys when tool behavior changes without source changes:
configure_step("lint", {
patterns = { "src/**/*.cpp" },
lint_rev = "2", -- bump when clang-tidy config changes
})Success cache (per-file) also uses step config. See Success Cache.
Any JSON-like Lua table is allowed: strings, numbers, booleans, nested tables, string arrays.
Avoid storing functions in config tables (they are not serialized for caching).
-
Step Context -
ctx.get_config(),ctx.glob() - Task Declaration - per-invocation config overlay
- DSL Patterns - incremental lint/format pattern
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