Conversation
Reviewer's GuideThis PR introduces a new deterministic Ninja build file generator (ninja_gen) using Display-based formatting with stable sorting and deduplication, enriches documentation with class diagrams and updated roadmap entries, updates the CI workflow to display and verify the Ninja version, adds necessary dependencies for generation and testing, and greatly expands unit and integration test coverage (including snapshot and Cucumber tests). Class diagram for IR and Ninja generatorclassDiagram
class BuildGraph {
+HashMap<String, Action> actions
+HashMap<PathBuf, BuildEdge> targets
+Vec<PathBuf> default_targets
}
class Action {
+Recipe recipe
+Option<String> description
+Option<String> depfile
+Option<String> deps_format
+Option<String> pool
+bool restat
}
class BuildEdge {
+String action_id
+Vec<PathBuf> inputs
+Vec<PathBuf> explicit_outputs
+Vec<PathBuf> implicit_outputs
+Vec<PathBuf> order_only_deps
+bool phony
+bool always
}
class Recipe {
<<enum>>
Command
Script
Rule
}
class ninja_gen {
+generate(graph: &BuildGraph) String
}
BuildGraph "1" o-- "many" Action : actions
BuildGraph "1" o-- "many" BuildEdge : targets
Action "1" o-- "1" Recipe
BuildEdge "1" --> "1" Action : action_id
ninja_gen ..> BuildGraph : uses
ninja_gen ..> Action : uses
ninja_gen ..> BuildEdge : uses
ninja_gen ..> Recipe : uses
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Summary by CodeRabbitNew Features
Documentation
Tests
Chores
WalkthroughIntroduce a Ninja build file generator module ( Changes
Sequence Diagram(s)sequenceDiagram
participant Manifest
participant IR (BuildGraph)
participant NinjaGen
participant NinjaFile
participant NinjaTool
Manifest->>IR (BuildGraph): Parse manifest to IR
IR (BuildGraph)->>NinjaGen: Pass BuildGraph for generation
NinjaGen->>NinjaFile: Generate Ninja file content
NinjaFile->>NinjaTool: Ninja tool consumes generated file
NinjaTool-->>NinjaFile: Build/validate targets
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~18 minutes Possibly related PRs
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (4)
🧰 Additional context used📓 Path-based instructions (2)**/*.rs⚙️ CodeRabbit Configuration File
Files:
**/*.md⚙️ CodeRabbit Configuration File
Files:
🧠 Learnings (1)📚 Learning: applies to docs/src/ir.rs : implement the ir::from_manifest transformation logic to convert the ast ...Applied to files:
🧬 Code Graph Analysis (1)tests/ninja_snapshot_tests.rs (3)
🔇 Additional comments (13)
✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @leynos - I've reviewed your changes and they look great!
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `tests/ninja_snapshot_tests.rs:25` </location>
<code_context>
+
+#[test]
+fn touch_manifest_ninja_validation() {
+ Command::new("ninja")
+ .arg("--version")
+ .output()
+ .expect("ninja must be installed for integration tests");
+ let manifest_yaml = r#"
</code_context>
<issue_to_address>
Consider skipping the test if Ninja is not installed.
The test currently fails if Ninja is missing, which can disrupt CI and local runs. Use `#[ignore]` or a runtime check to skip the test with a clear message when Ninja isn't available.
</issue_to_address>
<suggested_fix>
<<<<<<< SEARCH
#[test]
fn touch_manifest_ninja_validation() {
Command::new("ninja")
.arg("--version")
.output()
.expect("ninja must be installed for integration tests");
let manifest_yaml = r#"
=======
#[test]
fn touch_manifest_ninja_validation() {
let ninja_check = Command::new("ninja")
.arg("--version")
.output();
if ninja_check.is_err() || !ninja_check.as_ref().unwrap().status.success() {
eprintln!("skipping test: ninja must be installed for integration tests");
return;
}
let manifest_yaml = r#"
>>>>>>> REPLACE
</suggested_fix>
### Comment 2
<location> `src/ninja_gen.rs:76` </location>
<code_context>
+ action: &'a crate::ir::Action,
+}
+
+impl Display for NamedAction<'_> {
+ fn fmt(&self, f: &mut Formatter<'_>) -> fmt::Result {
+ writeln!(f, "rule {}", self.id)?;
</code_context>
<issue_to_address>
Consider introducing a small macro to handle repeated key-value writing logic in Display implementations.
Consider collapsing all those repetitive `if let Some(...) { writeln!(f, " key = {}", val)?; }` calls into a tiny helper. For example, at the top of the file:
```rust
macro_rules! write_kv {
($f:expr, $key:expr, $opt:expr) => {
if let Some(v) = $opt {
writeln!($f, " {} = {}", $key, v)?;
}
};
}
```
Then your `impl Display for NamedAction` becomes:
```rust
impl Display for NamedAction<'_> {
fn fmt(&self, f: &mut Formatter<'_>) -> fmt::Result {
writeln!(f, "rule {}", self.id)?;
match &self.action.recipe {
Recipe::Command { command } => writeln!(f, " command = {command}")?,
Recipe::Script { script } => {
writeln!(f, " command = /bin/sh -e -c \"")?;
for line in script.lines() {
writeln!(f, " {line}")?;
}
writeln!(f, " \"")?;
}
Recipe::Rule { .. } => unreachable!(),
}
write_kv!(f, "description", &self.action.description);
write_kv!(f, "depfile", &self.action.depfile);
write_kv!(f, "deps", &self.action.deps_format);
write_kv!(f, "pool", &self.action.pool);
if self.action.restat {
writeln!(f, " restat = 1")?;
}
writeln!(f)
}
}
```
You can apply the same macro-oriented approach in `DisplayEdge` to shrink its boilerplate as well. This keeps all functionality, but makes both impls far more declarative and easier to scan.
</issue_to_address>
### Comment 3
<location> `docs/roadmap.md:58` </location>
<code_context>
- - [ ] Implement the Ninja file synthesizer in
- [src/ninja_gen.rs](src/ninja_gen.rs) to traverse the BuildGraph IR.
+ - [x] Implement the Ninja file synthesizer in
+ [src/ninja_gen.rs](src/ninja_gen.rs) to traverse the BuildGraph IR. *(done)*
</code_context>
<issue_to_address>
Bullet point exceeds 80 columns and should be wrapped for readability.
Please wrap this bullet point so that no line exceeds 80 columns, as per the documentation guidelines.
</issue_to_address>
### Comment 4
<location> `docs/roadmap.md:61` </location>
<code_context>
- - [ ] Write logic to generate Ninja rule statements from ir::Action structs
- and build statements from ir::BuildEdge structs.
+ - [x] Write logic to generate Ninja rule statements from ir::Action structs
+ and build statements from ir::BuildEdge structs. *(done)*
</code_context>
<issue_to_address>
Bullet point exceeds 80 columns and should be wrapped for readability.
Please wrap this bullet point so that no line exceeds 80 columns, as per the documentation guidelines.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (2)
Cargo.lockis excluded by!**/*.locktests/snapshots/ninja/ninja_snapshot_tests__touch_manifest_ninja.snapis excluded by!**/*.snap
📒 Files selected for processing (12)
.github/workflows/ci.yml(1 hunks)Cargo.toml(2 hunks)docs/netsuke-design.md(2 hunks)docs/roadmap.md(1 hunks)src/lib.rs(1 hunks)src/ninja_gen.rs(1 hunks)tests/cucumber.rs(1 hunks)tests/features/ninja.feature(1 hunks)tests/ninja_gen_tests.rs(1 hunks)tests/ninja_snapshot_tests.rs(1 hunks)tests/steps/mod.rs(1 hunks)tests/steps/ninja_steps.rs(1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
Cargo.toml
📄 CodeRabbit Inference Engine (AGENTS.md)
Cargo.toml: Use explicit version ranges inCargo.tomland keep dependencies up-to-date.
Mandate caret requirements for all dependencies: All crate versions specified inCargo.tomlmust use SemVer-compatible caret requirements (e.g.,some-crate = "1.2.3").
Prohibit unstable version specifiers: The use of wildcard (*) or open-ended inequality (>=) version requirements is strictly forbidden. Tilde requirements (~) should only be used where a dependency must be locked to patch-level updates for a specific, documented reason.
Files:
Cargo.toml
**/*.rs
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*.rs: Clippy warnings MUST be disallowed.
Fix any warnings emitted during tests in the code itself rather than silencing them.
Where a function is too long, extract meaningfully named helper functions adhering to separation of concerns and CQRS.
Where a function has too many parameters, group related parameters in meaningfully named structs.
Where a function is returning a large error consider usingArcto reduce the amount of data returned.
Write unit and behavioural tests for new functionality. Run both before and after making any change.
Every module must begin with a module level (//!) comment explaining the module's purpose and utility.
Document public APIs using Rustdoc comments (///) so documentation can be generated with cargo doc.
Prefer immutable data and avoid unnecessarymutbindings.
Handle errors with theResulttype instead of panicking where feasible.
Avoidunsafecode unless absolutely necessary and document any usage clearly.
Place function attributes after doc comments.
Do not usereturnin single-line functions.
Use predicate functions for conditional criteria with more than two branches.
Lints must not be silenced except as a last resort.
Lint rule suppressions must be tightly scoped and include a clear reason.
Preferexpectoverallow.
Prefer.expect()over.unwrap().
Useconcat!()to combine long string literals rather than escaping newlines with a backslash.
Prefer semantic error enums: Derivestd::error::Error(via thethiserrorcrate) for any condition the caller might inspect, retry, or map to an HTTP status.
Use an opaque error only at the app boundary: Useeyre::Reportfor human-readable logs; these should not be exposed in public APIs.
Never export the opaque type from a library: Convert to domain enums at API boundaries, and toeyreonly in the mainmain()entrypoint or top-level async task.
Files:
tests/steps/mod.rstests/cucumber.rssrc/lib.rssrc/ninja_gen.rstests/ninja_snapshot_tests.rstests/steps/ninja_steps.rstests/ninja_gen_tests.rs
⚙️ CodeRabbit Configuration File
**/*.rs: * Seek to keep the cyclomatic complexity of functions no more than 12.
Adhere to single responsibility and CQRS
Place function attributes after doc comments.
Do not use
returnin single-line functions.Move conditionals with >2 branches into a predicate function.
Avoid
unsafeunless absolutely necessary.Every module must begin with a
//!doc comment that explains the module's purpose and utility.Comments and docs must follow en-GB-oxendict (-ize / -our) spelling and grammar
Lints must not be silenced except as a last resort.
#[allow]is forbidden.- Only narrowly scoped
#[expect(lint, reason = "...")]is allowed.- No lint groups, no blanket or file-wide suppression.
- Include
FIXME:with link if a fix is expected.Use
rstestfixtures for shared setup and to avoid repetition between tests.Replace duplicated tests with
#[rstest(...)]parameterised cases.Prefer
mockallfor mocks/stubs.Prefer
.expect()over.unwrap()Ensure that any API or behavioural changes are reflected in the documentation in
docs/Ensure that any completed roadmap steps are recorded in the appropriate roadmap in
docs/Files must not exceed 400 lines in length
- Large modules must be decomposed
- Long match statements or dispatch tables should be decomposed by domain and collocated with targets
- Large blocks of inline data (e.g., test fixtures, constants or templates) must be moved to external files and inlined at compile-time or loaded at run-time.
Files:
tests/steps/mod.rstests/cucumber.rssrc/lib.rssrc/ninja_gen.rstests/ninja_snapshot_tests.rstests/steps/ninja_steps.rstests/ninja_gen_tests.rs
docs/**/*.md
📄 CodeRabbit Inference Engine (AGENTS.md)
docs/**/*.md: Use the markdown files within thedocs/directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions.
Proactively update the relevant file(s) in thedocs/directory to reflect the latest state when new decisions are made, requirements change, libraries are added/removed, or architectural patterns evolve.
Files:
docs/roadmap.mddocs/netsuke-design.md
**/*.md
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*.md: Documentation must use en-GB-oxendict spelling and grammar, except for the naming of the "LICENSE" file.
Validate Markdown files usingmake markdownlint.
Runmake fmtafter any documentation changes to format all Markdown files and fix table markup.
Validate Mermaid diagrams in Markdown files by runningmake nixie.
Markdown paragraphs and bullet points must be wrapped at 80 columns.
Code blocks in Markdown must be wrapped at 120 columns.
Tables and headings in Markdown must not be wrapped.
Use dashes (-) for list bullets in Markdown.
Use GitHub-flavoured Markdown footnotes ([^1]) for references and footnotes.
Files:
docs/roadmap.mddocs/netsuke-design.md
⚙️ CodeRabbit Configuration File
**/*.md: * Avoid 2nd person or 1st person pronouns ("I", "you", "we")
- Use en-GB-oxendict (-ize / -our) spelling and grammar
- Paragraphs and bullets must be wrapped to 80 columns, except where a long URL would prevent this (in which case, silence MD013 for that line)
- Code blocks should be wrapped to 120 columns.
- Headings must not be wrapped.
- Documents must start with a level 1 heading
- Headings must correctly increase or decrease by no more than one level at a time
- Use GitHub-flavoured Markdown style for footnotes and endnotes.
- Numbered footnotes must be numbered by order of appearance in the document.
Files:
docs/roadmap.mddocs/netsuke-design.md
🧠 Learnings (3)
📚 Learning: applies to docs/src/ninja_gen.rs : implement the ninja file synthesizer in src/ninja_gen.rs to trave...
Learnt from: CR
PR: leynos/netsuke#0
File: docs/roadmap.md:0-0
Timestamp: 2025-07-27T17:59:36.506Z
Learning: Applies to docs/src/ninja_gen.rs : Implement the Ninja file synthesizer in src/ninja_gen.rs to traverse the BuildGraph IR.
Applied to files:
docs/roadmap.md
📚 Learning: applies to docs/src/ninja_gen.rs : write logic to generate ninja rule statements from ir::action str...
Learnt from: CR
PR: leynos/netsuke#0
File: docs/roadmap.md:0-0
Timestamp: 2025-07-27T17:59:36.506Z
Learning: Applies to docs/src/ninja_gen.rs : Write logic to generate Ninja rule statements from ir::Action structs and build statements from ir::BuildEdge structs.
Applied to files:
docs/roadmap.md
📚 Learning: applies to docs/src/ir.rs : implement the ir::from_manifest transformation logic to convert the ast ...
Learnt from: CR
PR: leynos/netsuke#0
File: docs/roadmap.md:0-0
Timestamp: 2025-07-27T17:59:36.506Z
Learning: Applies to docs/src/ir.rs : Implement the ir::from_manifest transformation logic to convert the AST into the BuildGraph IR.
Applied to files:
docs/netsuke-design.md
🧬 Code Graph Analysis (2)
tests/steps/ninja_steps.rs (1)
src/ninja_gen.rs (1)
generate(20-56)
tests/ninja_gen_tests.rs (1)
src/ninja_gen.rs (1)
generate(20-56)
🔇 Additional comments (22)
src/lib.rs (1)
11-11: LGTM! Module declaration follows proper conventions.The
ninja_genmodule is correctly declared and maintains alphabetical ordering with other public modules.tests/steps/mod.rs (1)
4-4: LGTM! Module declaration maintains proper ordering.The
ninja_stepsmodule is correctly declared and preserves alphabetical ordering with other step modules.tests/cucumber.rs (1)
10-10: LGTM! Field addition follows established patterns.The
ninjafield correctly extends theCliWorldstruct using the sameOption<String>pattern as other state fields.Cargo.toml (2)
15-15: LGTM! Dependency follows version requirements.The
itertoolsdependency correctly uses caret versioning and maintains alphabetical ordering.
61-62: LGTM! Dev dependencies properly configured.Both
instawith yaml feature andtempfileuse appropriate caret versioning and support the new testing infrastructure.docs/roadmap.md (1)
58-62: LGTM! Roadmap updates accurately reflect completed work.The completed tasks are properly documented with cross-references to the implementation, maintaining clear project tracking.
tests/features/ninja.feature (1)
1-13: Well-structured feature tests covering core Ninja generation scenarios.The scenarios effectively validate both standard builds and phony targets, providing good behavioural test coverage for the new functionality.
docs/netsuke-design.md (2)
963-1004: Excellent class diagram illustrating the IR and generator architecture.The Mermaid diagram clearly shows the relationships between data structures and the ninja_gen generator, providing valuable architectural documentation.
1117-1122: Important design notes ensuring deterministic builds.The documentation of sorting and deduplication strategies is crucial for cross-platform stability and aligns well with the implementation approach.
tests/steps/ninja_steps.rs (1)
1-27: Well-implemented Cucumber step definitions.The steps correctly handle the test workflow, use proper error handling with descriptive messages, and appropriately manage the clippy lint for Cucumber's String requirements.
src/ninja_gen.rs (4)
1-6: Excellent module documentation.The module doc clearly explains the purpose and highlights the deterministic output guarantee, which is crucial for reproducible builds.
63-68: Solid path key generation for cross-platform stability.The path_key function correctly normalises paths and uses null separator for uniqueness. The sorting ensures deterministic ordering across platforms.
147-181: Comprehensive test covering the main generation workflow.The test validates rule generation, build edge formatting, and default target handling with a realistic example.
29-47: Resolve edge deduplication logic
Deduplication by the full set of explicit outputs is intentional and documented in docs/netsuke-design.md. No changes required.tests/ninja_snapshot_tests.rs (4)
1-12: Excellent module documentation and imports.The module documentation clearly explains the purpose and testing strategy. Imports are well-organised and necessary for the functionality.
13-21: Well-implemented helper function with proper error handling.Good use of
expectwith descriptive messages and appropriate error context when commands fail.
23-56: Solid test setup with good error handling.The test properly checks for Ninja availability and handles errors appropriately. The embedded YAML manifest is acceptable for this test size, though consider moving to an external file if it grows significantly larger.
57-80: Comprehensive integration testing with excellent validation.The test thoroughly validates the generated Ninja file through multiple operations and includes the crucial no-op second build check. The closure pattern for Ninja commands is clean and maintainable.
tests/ninja_gen_tests.rs (4)
9-41: Well-structured test for phony target generation.Good use of
concat!for string literals and proper validation of Ninja syntax for phony builds.
43-75: Solid test coverage for standard build scenarios.The test appropriately covers the common compilation use case with multiple inputs and validates correct Ninja syntax generation.
77-109: Excellent coverage of complex dependency scenarios.The test properly validates the generation of multiple explicit outputs, implicit outputs (|), and order-only dependencies (||) with correct Ninja syntax.
111-116: Good edge case coverage for empty graphs.Proper validation that empty build graphs produce empty output, ensuring graceful handling of edge cases.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@sourcery-ai review |
There was a problem hiding this comment.
Hey @leynos - I've reviewed your changes - here's some feedback:
- Instead of silently returning in integration tests when Ninja is missing, consider using #[ignore] or a test-harness skip mechanism so that missing prerequisites are reported as skipped tests rather than no-ops.
- The CI workflow currently only prints the Ninja version; consider parsing that output and enforcing a minimum supported version to fail early on incompatible environments.
- The deduplication in ninja_gen.generate only keys off explicit outputs—edges that differ only by implicit outputs or inputs will be collapsed, so you may want to expand the key or document this trade-off.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Instead of silently returning in integration tests when Ninja is missing, consider using #[ignore] or a test-harness skip mechanism so that missing prerequisites are reported as skipped tests rather than no-ops.
- The CI workflow currently only prints the Ninja version; consider parsing that output and enforcing a minimum supported version to fail early on incompatible environments.
- The deduplication in ninja_gen.generate only keys off explicit outputs—edges that differ only by implicit outputs or inputs will be collapsed, so you may want to expand the key or document this trade-off.
## Individual Comments
### Comment 1
<location> `tests/features/ninja.feature:1` </location>
<code_context>
+Feature: Ninja file generation
+
+ Scenario: Generate build statements
</code_context>
<issue_to_address>
Consider replacing the Cucumber feature file with direct Rust tests to simplify the test suite.
Consider replacing the Cucumber feature with a couple of focused Rust tests—either plain `assert!` checks or a snapshot test—so you keep all of the coverage but remove the extra BDD layer.
1) Delete `features/ninja.feature`.
2) Add something like this in `tests/ninja_generation.rs`:
```rust
use mycrate::{compile_manifest, generate_ninja};
#[test]
fn generate_rules() {
let ir = compile_manifest("tests/data/rules.yml").unwrap();
let ninja = generate_ninja(&ir);
assert!(ninja.contains("rule"), "expected a rule block");
assert!(ninja.contains("build hello.o:"), "expected hello.o build");
}
#[test]
fn generate_phony() {
let ir = compile_manifest("tests/data/phony.yml").unwrap();
let ninja = generate_ninja(&ir);
assert!(ninja.contains("build clean: phony"), "expected phony target");
}
```
3) (Optional) If you want full-file regression, you can use insta:
```rust
use insta::assert_snapshot;
use mycrate::{compile_manifest, generate_ninja};
#[test]
fn ninja_rules_snapshot() {
let ir = compile_manifest("tests/data/rules.yml").unwrap();
let ninja = generate_ninja(&ir);
assert_snapshot!(ninja);
}
```
</issue_to_address>
### Comment 2
<location> `tests/steps/ninja_steps.rs:8` </location>
<code_context>
+use netsuke::ninja_gen;
+
+#[when("the ninja file is generated")]
+fn generate_ninja(world: &mut CliWorld) {
+ let graph = world
+ .build_graph
</code_context>
<issue_to_address>
Consider extracting repeated logic into `CliWorld` helper methods to make step handlers one-liners.
Consider moving the `as_ref().expect()` and generation/assertion logic into `CliWorld` helpers so each step handler is a one-liner. For example:
```rust
// in src/cli_world.rs
impl CliWorld {
pub fn generate_ninja(&mut self) {
let graph = self
.build_graph
.as_ref()
.expect("build graph should be available");
self.ninja = Some(netsuke::ninja_gen::generate(graph));
}
pub fn assert_ninja_contains(&self, expected: &str) {
let ninja = self
.ninja
.as_ref()
.expect("ninja content should be available");
assert!(
ninja.contains(expected),
"expected ninja to contain {:?}, got {:?}",
expected,
ninja
);
}
}
```
Then shrink each step definition to:
```rust
#[when("the ninja file is generated")]
fn generate_ninja(world: &mut CliWorld) {
world.generate_ninja();
}
#[then(expr = "the ninja file contains {string}")]
fn ninja_contains(world: &mut CliWorld, text: String) {
world.assert_ninja_contains(&text);
}
```
This preserves cucumber steps but removes the repeated boilerplate and keeps the fns trivial.
</issue_to_address>
### Comment 3
<location> `docs/netsuke-design.md:965` </location>
<code_context>
+```mermaid
+classDiagram
+ class BuildGraph {
+ +HashMap<String, Action> actions
+ +HashMap<PathBuf, BuildEdge> targets
</code_context>
<issue_to_address>
Mermaid code block lines exceed 120 columns and should be wrapped accordingly.
The lines in the added Mermaid diagram code block are longer than 120 columns, which violates the wrapping guideline for code blocks. Please wrap these lines to a maximum of 120 columns.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
1 participant
Summary
ninja_genusing Display implsTesting
make lintmake testmake markdownlintmake nixie(fails: FileNotFound for commander package)https://chatgpt.com/codex/tasks/task_e_688a921dd3f08322b003b278f13cdce5
Summary by Sourcery
Introduce deterministic Ninja build file generation support, update CI to display Ninja version, enhance design documentation with class diagrams, and expand testing coverage for the Ninja generator.
New Features:
Enhancements:
Build:
CI:
Documentation:
Tests: