The README makes claims. This file backs them up.
conflow intelligently orchestrates CUE, Nickel, and configuration validation workflows. Instead of running tools sequentially by hand, describe your pipeline once and conflow handles dependency management, caching, and error recovery.
This solves the problem: "You have configuration files and you’re not sure whether to use CUE, Nickel, or both." conflow analyzes your configs, recommends the right tool, and chains them with smart caching.
Location: /var/mnt/eclipse/repos/conflow/src/analyzer/complexity.rs (Rust complexity metrics)
How verified: The analyzer scans YAML/JSON configs and assigns scores on three dimensions: structure (nesting depth, number of keys), logic (conditionals, loops, functions), and imports (dependencies on other files). README (§When to Use What?) claims "Use CUE when validating configuration" and "Use Nickel when generating configurations." The recommender (in src/analyzer/recommender.rs) applies heuristics: if logic_score > 0.6, recommend Nickel; if structure_score > 0.7 and logic < 0.3, recommend CUE. The analysis is demonstrated in examples/ where complexity.rs generates JSON output showing why each tool was picked.
Caveat: Heuristics are empirical, not formally justified. A config that scores 0.5/0.5 on logic and structure will arbitrarily pick the first matching rule.
Location: /var/mnt/eclipse/repos/conflow/src/pipeline/executor.rs (Rust pipeline executor with caching)
How verified: The executor reads a .conflow.yaml pipeline definition, builds a directed acyclic graph (DAG) of stages with depends_on edges, topologically sorts it, and executes stages in order. README (§Example Pipeline) shows a 3-stage pipeline: generate (Nickel) → validate (CUE) → export (CUE). The executor validates the DAG is acyclic (rejects cycles), then for each stage, checks if inputs changed using BLAKE3 hashes (in src/cache/hash.rs). If unchanged, it skips execution and retrieves cached output. This is verified in tests that confirm stages run in correct order and cache hits are recorded.
Caveat: Caching is content-addressed by input paths, not by actual input contents. If an input file is updated but its path and size remain the same, the cache will wrongly report a hit (false positive on cache staleness).
conflow is dogfooded in civic-connect (Nickel policies), docmatrix (format transformations), and configuration management repos. Uses Justfile for builds (not shell scripts) and integrates with RSR compliance checking.
| Path | What’s There |
|---|---|
|
CLI entry point; clap argument parsing for init, analyze, run, validate, watch, graph, cache, rsr commands |
|
Pipeline, Stage, Tool types; parses YAML pipeline definitions |
|
Dependency graph builder and topological sort; cycle detection |
|
Stage executor; runs CUE/Nickel/shell tools in dependency order |
|
CUE executor: calls |
|
Nickel executor: calls |
|
Shell executor: runs arbitrary shell commands (careful with security!) |
|
Content-addressed cache using file paths and BLAKE3 hashes |
|
BLAKE3 content hashing for cache keys |
|
Complexity scoring: structure, logic, imports |
|
Heuristic tool recommendation (CUE vs Nickel) |
|
Format detection (YAML, JSON, CUE, Nickel) |
|
RSR Bronze/Silver compliance checking |
|
Auto-fix common issues (missing docs, license headers, etc.) |
|
Example pipeline definition |
|
Example configurations and pipelines |
-
DAG construction:
src/pipeline/dag.rstests — verify cycles are rejected, topological sort is correct -
Caching:
tests/cache_test.rs— verify cache hits/misses, content addressing, cleanup -
Complexity analysis:
tests/analyzer_test.rs— test scoring on synthetic configs -
Executor:
tests/executor_test.rs— mock CUE/Nickel, verify stage order, input/output handling -
Integration:
tests/integration/— full pipelines with real CUE/Nickel tools (optional, requires tools installed)