Skip to content

Implement steps parsing with phony default#30

Merged
leynos merged 9 commits intomainfrom
codex/implement-actions-list-parsing-feature
Jul 25, 2025
Merged

Implement steps parsing with phony default#30
leynos merged 9 commits intomainfrom
codex/implement-actions-list-parsing-feature

Conversation

@leynos
Copy link
Copy Markdown
Owner

@leynos leynos commented Jul 23, 2025

Summary

  • ensure steps list entries are marked phony on load
  • update design notes about step deserialisation
  • mark roadmap item for steps parsing as done
  • cover steps parsing with unit and behavioural tests

Testing

  • make fmt
  • make lint
  • make test
  • make markdownlint

https://chatgpt.com/codex/tasks/task_e_6881498e6da08322a1cf81533393c641

Summary by Sourcery

Enable parsing of a new 'steps' section in the manifest with a custom deserializer that treats all steps as phony tasks by default, update documentation and tests to cover this behavior

New Features:

  • Parse top-level steps section from the manifest and implicitly mark each step as phony

Enhancements:

  • Implement custom deserialize_steps helper and annotate steps field in AST to enforce phony default

Documentation:

  • Update design documentation to describe custom deserialization of steps as phony and fix markdown code fences
  • Mark steps parsing roadmap item as done

Tests:

  • Add unit tests to verify steps are marked phony by default, override behavior, and missing fields error
  • Add Cucumber scenarios and step definitions for validating step phony status and parse failures
  • Include fixture files for valid and invalid steps manifests

@sourcery-ai
Copy link
Copy Markdown
Contributor

sourcery-ai Bot commented Jul 23, 2025

Reviewer's Guide

Adds a custom deserializer for top-level steps in the AST to ensure they are always marked as phony, complemented by new unit and BDD tests, updated fixtures, and documentation and roadmap updates.

Class diagram for NetsukeManifest steps deserialization

classDiagram
    class NetsukeManifest {
        Vec<Rule> rules
        Vec<Target> steps
        Vec<Target> targets
    }
    class Target {
        bool phony
        bool always
        ...
    }
    NetsukeManifest --> "*" Target : steps
    NetsukeManifest --> "*" Target : targets
    %% Custom deserializer for steps
    class deserialize_steps {
        <<function>>
    }
    NetsukeManifest : steps [deserialize_with = "deserialize_steps"]
    deserialize_steps --> Target : marks as phony
Loading

File-Level Changes

Change Details Files
Custom deserialization for steps to enforce phony default
  • Added deserialize_steps helper and applied it to the steps field
  • Updated serde attribute and doc comment on NetsukeManifest.steps
  • Ensures all loaded steps default to phony during deserialization
src/ast.rs
Unit tests covering steps parsing behavior
  • Tested default phony flag on loaded steps
  • Verified phony override is honored
  • Asserted parse failure on missing required fields
tests/ast_tests.rs
BDD scenarios and step definitions for step parsing
  • Added Gherkin scenarios for phony and invalid steps
  • Implemented corresponding step functions in manifest_steps.rs
tests/features/manifest.feature
tests/steps/manifest_steps.rs
YAML fixtures for valid and invalid step manifests
  • Added steps.yml for valid step with phony override
  • Added step_invalid.yml to test missing fields error
tests/data/steps.yml
tests/data/step_invalid.yml
Documentation and markdown updates for steps parsing
  • Updated netsuke-design.md with step deserialization notes and fixed code fences
  • Marked steps parsing done in roadmap.md
  • Fixed markdown fences in behavioural-testing-in-rust-with-cucumber.md
docs/netsuke-design.md
docs/roadmap.md
docs/behavioural-testing-in-rust-with-cucumber.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Jul 23, 2025

Warning

Rate limit exceeded

@leynos has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 12 minutes and 0 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 4951b5d and 24476dd.

📒 Files selected for processing (2)
  • docs/behavioural-testing-in-rust-with-cucumber.md (1 hunks)
  • tests/data/action_invalid.yml (1 hunks)

Summary by CodeRabbit

  • Documentation

    • Updated terminology in documentation from "steps" to "actions" and clarified the behaviour of actions as always phony.
    • Improved formatting and consistency in footnote references and code blocks.
    • Marked the parsing of the actions list as completed in the roadmap.
  • New Features

    • Manifest now supports an "actions" list, with each action automatically treated as a phony target.
  • Bug Fixes

    • Ensured all actions are always marked as phony and never generate build artefacts.
  • Tests

    • Added and improved tests to verify correct parsing and behaviour of actions, including error handling for invalid actions.
    • Introduced new test data files and feature scenarios for actions.
    • Added step definitions to check action properties and parse errors.

Walkthrough

Rename the steps field in the NetsukeManifest struct and related documentation to actions, and enforce that all actions are deserialised as phony targets. Update related documentation, diagrams, tests, and add new test data and feature scenarios to verify the new behaviour and error handling.

Changes

File(s) Change Summary
docs/netsuke-design.md, src/ast.rs, tests/ast_tests.rs Rename steps to actions, update struct, deserialisation logic, documentation, and tests for phony semantics.
tests/data/actions.yml, tests/data/action_invalid.yml Add YAML test data files for valid and invalid actions.
tests/features/manifest.feature, tests/steps/manifest_steps.rs Add feature scenarios and step definitions for phony actions and manifest parse errors.
docs/behavioural-testing-in-rust-with-cucumber.md Correct indentation in a footnote URL.
docs/roadmap.md Mark checklist item for parsing actions as phony as done.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant ManifestLoader
    participant NetsukeManifest
    participant Target

    User->>ManifestLoader: Load manifest YAML
    ManifestLoader->>NetsukeManifest: Deserialize YAML
    NetsukeManifest->>Target: Deserialize actions with custom logic
    Target-->>NetsukeManifest: Set phony = true for each action
    NetsukeManifest-->>ManifestLoader: Return manifest with actions marked phony
    ManifestLoader-->>User: Manifest ready for build process
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~18 minutes

Possibly related PRs

Poem

Actions arise, steps retire,
Each phony flag set to inspire.
YAMLs align, tests now sing,
Manifests parse with a confident ring.
In code and docs, the changes dance—
Netsuke’s build gets a phony advance!
🛠️✨

✨ Finishing Touches
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch codex/implement-actions-list-parsing-feature

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need 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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Copy Markdown

@codescene-delta-analysis codescene-delta-analysis Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gates Failed
Enforce advisory code health rules (1 file with Code Duplication)

Gates Passed
5 Quality Gates Passed

See analysis details in CodeScene

Reason for failure
Enforce advisory code health rules Violations Code Health Impact
ast_tests.rs 1 advisory rule 10.00 → 9.39 Suppress

Quality Gate Profile: Pay Down Tech Debt
Want more control? Customize Code Health rules or catch issues early with our IDE extension and CLI tool.

Comment thread tests/ast_tests.rs Outdated
Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @leynos - I've reviewed your changes and found some issues that need to be addressed.

Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments

### Comment 1
<location> `tests/ast_tests.rs:249` </location>
<code_context>
 }
+
+#[test]
+fn steps_are_marked_phony() {
+    let yaml = r#"
+        netsuke_version: "1.0.0"
+        steps:
+          - name: setup
+            recipe:
+              kind: command
+              command: "echo hi"
+        targets:
+          - name: done
+            recipe:
+              kind: command
+              command: "true"
+    "#;
+    let manifest = serde_yml::from_str::<NetsukeManifest>(yaml).expect("parse");
+    let step = manifest.steps.first().expect("step");
+    assert!(step.phony);
+    assert!(!step.always);
+}
+
</code_context>

<issue_to_address>
Consider adding a test for multiple steps.

Adding a test with multiple steps will verify that all steps are correctly marked as phony, not just the first one.

Suggested implementation:

```rust

#[test]
fn steps_are_marked_phony() {
    let yaml = r#"
        netsuke_version: "1.0.0"
        steps:
          - name: setup
            recipe:
              kind: command
              command: "echo hi"
        targets:

```

```rust
}

#[test]
fn multiple_steps_are_marked_phony() {
    let yaml = r#"
        netsuke_version: "1.0.0"
        steps:
          - name: setup
            recipe:
              kind: command
              command: "echo hi"
          - name: build
            recipe:
              kind: command
              command: "make build"
          - name: test
            recipe:
              kind: command
              command: "cargo test"
        targets:
          - name: done
            recipe:
              kind: command
              command: "true"
    "#;
    let manifest = serde_yml::from_str::<NetsukeManifest>(yaml).expect("parse");
    assert_eq!(manifest.steps.len(), 3);
    for step in &manifest.steps {
        assert!(step.phony, "Step '{}' should be phony", step.name);
        assert!(!step.always, "Step '{}' should not be always", step.name);
    }
}

```
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread tests/ast_tests.rs Outdated
Comment thread tests/ast_tests.rs Outdated
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🔭 Outside diff range comments (2)
tests/data/action_invalid.yml (1)

10-11: Remove excessive blank lines to comply with YAML formatting standards.

The file contains too many blank lines at the end. Remove the extra blank line to satisfy YAMLlint requirements.

-
-
+
tests/data/actions.yml (1)

13-14: Remove excessive blank lines to comply with YAML formatting standards.

The file contains too many blank lines at the end. Remove the extra blank line to satisfy YAMLlint requirements.

-

+
♻️ Duplicate comments (1)
tests/ast_tests.rs (1)

331-360: LGTM! Addresses previous feedback on multiple actions testing.

The test properly verifies that all actions in a list are marked as phony, addressing the previous suggestion to test multiple actions rather than just the first one.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0c626ee and 9b6d940.

📒 Files selected for processing (9)
  • docs/behavioural-testing-in-rust-with-cucumber.md (1 hunks)
  • docs/netsuke-design.md (10 hunks)
  • docs/roadmap.md (1 hunks)
  • src/ast.rs (3 hunks)
  • tests/ast_tests.rs (3 hunks)
  • tests/data/action_invalid.yml (1 hunks)
  • tests/data/actions.yml (1 hunks)
  • tests/features/manifest.feature (1 hunks)
  • tests/steps/manifest_steps.rs (1 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
docs/**/*.md

📄 CodeRabbit Inference Engine (AGENTS.md)

docs/**/*.md: Use the markdown files within the docs/ directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions.
Proactively update the relevant file(s) in the docs/ directory to reflect the latest state when new decisions are made, requirements change, libraries are added/removed, or architectural patterns evolve.
Documentation must use en-GB-oxendict spelling and grammar (with the exception of 'license' which is to be left unchanged for community consistency).

Files:

  • docs/behavioural-testing-in-rust-with-cucumber.md
  • docs/roadmap.md
  • docs/netsuke-design.md
**/*.md

📄 CodeRabbit Inference Engine (AGENTS.md)

**/*.md: Validate Markdown files using make markdownlint.
Run make fmt after any documentation changes to format all Markdown files and fix table markup.
Validate Mermaid diagrams in Markdown files by running make 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.

Files:

  • docs/behavioural-testing-in-rust-with-cucumber.md
  • docs/roadmap.md
  • docs/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/behavioural-testing-in-rust-with-cucumber.md
  • docs/roadmap.md
  • docs/netsuke-design.md
**/*.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 using Arc to reduce the amount of data returned.
Document public APIs using Rustdoc comments (///) so documentation can be generated with cargo doc.
Every module must begin with a module level (//!) comment explaining the module's purpose and utility.
Prefer immutable data and avoid unnecessary mut bindings.
Handle errors with the Result type instead of panicking where feasible.
Avoid unsafe code unless absolutely necessary and document any usage clearly.
Place function attributes after doc comments.
Do not use return in 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.
Prefer expect over allow.
Prefer .expect() over .unwrap().

Files:

  • tests/steps/manifest_steps.rs
  • src/ast.rs
  • tests/ast_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 return in single-line functions.

  • Move conditionals with >2 branches into a predicate function.

  • Avoid unsafe unless 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 rstest fixtures for shared setup and to avoid repetition between tests.

  • Replace duplicated tests with #[rstest(...)] parameterised cases.

  • Prefer mockall for 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/manifest_steps.rs
  • src/ast.rs
  • tests/ast_tests.rs
**/*{_test,tests}.rs

📄 CodeRabbit Inference Engine (AGENTS.md)

**/*{_test,tests}.rs: Write unit and behavioural tests for new functionality. Run both before and after making any change.
Use rstest fixtures for shared setup.
Replace duplicated tests with #[rstest(...)] parameterised cases.
Prefer mockall for mocks/stubs.

Files:

  • tests/ast_tests.rs
🧠 Learnings (1)
docs/netsuke-design.md (1)

Learnt from: CR
PR: leynos/netsuke#0
File: docs/roadmap.md:0-0
Timestamp: 2025-07-20T02:49:27.706Z
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.

🪛 YAMLlint (1.37.1)
tests/data/action_invalid.yml

[error] 10-10: too many blank lines (1 > 0)

(empty-lines)

tests/data/actions.yml

[error] 13-13: too many blank lines (1 > 0)

(empty-lines)

🔇 Additional comments (14)
tests/features/manifest.feature (1)

13-19: Well-structured test scenarios for the actions feature.

The new scenarios effectively test the core functionality changes: enforcing phony behaviour for actions and validating parsing failures for invalid configurations. The Gherkin syntax is clear and follows established patterns.

docs/roadmap.md (1)

32-33: Appropriately marks the actions parsing feature as completed.

The update correctly reflects the completion of the actions parsing implementation and removes the redundant "steps" terminology, maintaining consistency with the schema changes.

tests/data/actions.yml (1)

7-7: Verify that the explicit phony: false setting tests the deserialization override.

The action explicitly sets phony: false, which should be overridden to true during deserialization according to the PR implementation. Ensure the corresponding test verifies this behaviour correctly.

tests/steps/manifest_steps.rs (2)

72-77: LGTM! Correct implementation of action phony verification.

The step definition properly verifies that actions are marked as phony by default, aligning with the new deserialization behavior.


79-82: LGTM! Proper error verification implementation.

The step definition correctly verifies that parsing failures are detected and stored in the test world state.

src/ast.rs (2)

21-32: LGTM! Correct custom deserializer implementation.

The deserialize_actions function properly enforces the phony default behavior for actions during deserialization. The implementation follows serde patterns and handles errors appropriately.


72-75: LGTM! Clear documentation and proper deserializer configuration.

The field documentation accurately describes the new actions behavior, and the deserialize_with attribute correctly applies the custom deserializer.

docs/netsuke-design.md (4)

180-181: LGTM! Accurate description of actions behavior.

The documentation correctly describes that actions are treated as phony by default, aligning with the implementation.


196-196: LGTM! Consistent ER diagram updates.

The ER diagram correctly reflects the field rename from steps to actions while maintaining proper relationships.

Also applies to: 226-226


424-424: LGTM! Code examples updated correctly.

The code examples properly reflect the field rename from steps to actions.

Also applies to: 522-522


593-598: LGTM! Clear explanation of custom deserializer behavior.

The design decisions section correctly explains that actions are deserialised using a custom helper to always be treated as phony tasks, ensuring they never generate build artefacts.

tests/ast_tests.rs (3)

7-10: LGTM! Excellent addition of helper function.

The parse_manifest helper reduces code duplication and improves test readability, addressing previous review feedback.


208-233: LGTM! Excellent use of parameterised tests.

The parsing_failures test properly uses rstest to eliminate duplication while maintaining comprehensive coverage of failure scenarios. The test correctly uses actions instead of the old steps field name.


266-329: LGTM! Comprehensive actions behavior testing.

The parameterised test properly verifies that actions are always marked as phony regardless of explicit flag values, correctly testing the custom deserializer behavior.

Comment thread docs/behavioural-testing-in-rust-with-cucumber.md Outdated
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9b6d940 and b6ba0f3.

📒 Files selected for processing (3)
  • docs/behavioural-testing-in-rust-with-cucumber.md (1 hunks)
  • tests/data/action_invalid.yml (1 hunks)
  • tests/data/actions.yml (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
docs/**/*.md

📄 CodeRabbit Inference Engine (AGENTS.md)

docs/**/*.md: Use the markdown files within the docs/ directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions.
Proactively update the relevant file(s) in the docs/ directory to reflect the latest state when new decisions are made, requirements change, libraries are added/removed, or architectural patterns evolve.
Documentation must use en-GB-oxendict spelling and grammar (with the exception of 'license' which is to be left unchanged for community consistency).

Files:

  • docs/behavioural-testing-in-rust-with-cucumber.md
**/*.md

📄 CodeRabbit Inference Engine (AGENTS.md)

**/*.md: Validate Markdown files using make markdownlint.
Run make fmt after any documentation changes to format all Markdown files and fix table markup.
Validate Mermaid diagrams in Markdown files by running make 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.

Files:

  • docs/behavioural-testing-in-rust-with-cucumber.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/behavioural-testing-in-rust-with-cucumber.md
🔇 Additional comments (1)
tests/data/action_invalid.yml (1)

1-9: Keep as-is – fixture is fit for purpose

The YAML cleanly represents the negative test case: phony: false violates the phony-by-default rule, field names match the updated schema, and quoting avoids YAML boolean coercion. No amendments required.

Comment thread docs/behavioural-testing-in-rust-with-cucumber.md Outdated
Comment thread tests/data/actions.yml Outdated
@leynos
Copy link
Copy Markdown
Owner Author

leynos commented Jul 25, 2025

@coderabbitai review

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Jul 25, 2025

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between da4ba6c and 4951b5d.

📒 Files selected for processing (2)
  • docs/behavioural-testing-in-rust-with-cucumber.md (1 hunks)
  • tests/data/action_invalid.yml (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
docs/**/*.md

📄 CodeRabbit Inference Engine (AGENTS.md)

docs/**/*.md: Use the markdown files within the docs/ directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions.
Proactively update the relevant file(s) in the docs/ directory to reflect the latest state when new decisions are made, requirements change, libraries are added/removed, or architectural patterns evolve.
Documentation must use en-GB-oxendict spelling and grammar (with the exception of 'license' which is to be left unchanged for community consistency).

Files:

  • docs/behavioural-testing-in-rust-with-cucumber.md
**/*.md

📄 CodeRabbit Inference Engine (AGENTS.md)

**/*.md: Validate Markdown files using make markdownlint.
Run make fmt after any documentation changes to format all Markdown files and fix table markup.
Validate Mermaid diagrams in Markdown files by running make 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.

Files:

  • docs/behavioural-testing-in-rust-with-cucumber.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/behavioural-testing-in-rust-with-cucumber.md
🪛 LanguageTool
docs/behavioural-testing-in-rust-with-cucumber.md

[typographical] ~1171-~1171: To join two clauses or introduce examples, consider using an em dash.
Context: ...ml> [^32]: CLI (command-line interface) - Cucumber Rust Book, accessed on 14 J...

(DASH_RULE)

🔇 Additional comments (1)
docs/behavioural-testing-in-rust-with-cucumber.md (1)

1167-1169: Footnote continuation indentation is correct – good fix
Four-space indentation matches the project’s Markdown rules and silences MD013 without disabling the rule.
No further changes required.

Comment thread docs/behavioural-testing-in-rust-with-cucumber.md Outdated
Comment thread tests/data/action_invalid.yml
@leynos leynos merged commit 9405778 into main Jul 25, 2025
2 checks passed
@leynos leynos deleted the codex/implement-actions-list-parsing-feature branch July 25, 2025 17:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant