Import Rust template tooling#32
Conversation
Add root guidance that identifies this repository as a Copier template and documents the pytest-copier test setup path. Record the living execution plan for the Rust template tooling import so future work can resume from repository evidence.
Render generated Rust projects with local Cranelift codegen, Linux mold linker configuration, nextest tests, Whitaker linting, crates.io metadata prompts, and cargo-binstall metadata for app projects. Import the dear-diary CI shape with SHA-pinned actions, Whitaker caching, mold installation, and an llvm-cov lld fallback. Strengthen pytest-copier coverage so rendered app and library projects pass their public make all gate.
Update the living execution plan with the committed tooling milestone, CodeRabbit disposition, and final validation status before the branch is pushed for review.
Capture the final post-milestone template test evidence in the living execution plan before pushing the branch for pull request review.
Update the living execution plan with the pushed branch and draft pull request URL so the repository captures the completed delivery state.
OverviewThis pull request imports Rust project tooling into the Copier template to support faster local Rust iteration, stricter linting, release automation, and comprehensive template validation. The implementation is documented in the new execution plan at Key ChangesConfiguration & Metadata
Build & Development Tooling
CI/CD & Release
Testing & Validation
Documentation
Dependencies & Infrastructure
Validation Notes
Execution Plan ReferenceDetailed project rationale, constraints, decisions, and outcomes are documented in WalkthroughAdd Copier inputs for package metadata and dev_target; emit extended Cargo metadata and optional app binstall block; enable Cranelift and conditional Linux mold linking; update Makefile to resolve Whitaker and wire coverage flags; change CI to cache/install Whitaker and run make test; add release workflow template; expand parent tests, docs and snapshots to validate generated projects. ChangesRust Template Tooling Enhancements
Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 18 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (18 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Drop the parent repository CI format and lint steps because the parent Makefile only exposes the supported template test target. Generated-project format and lint validation remains covered by pytest-copier rendering and make all.
Reviewer's GuideImports Rust tooling and metadata from an existing project into the Copier template so generated Rust apps/libs have Cranelift/mold setup, stricter linting, SHA-pinned CI, release workflows, and pytest-copier tests that exercise the generated public gates. Flow diagram for generated project tooling and gates (Cranelift, mold, nextest, Whitaker)flowchart LR
Dev[Developer] -->|copier copy| CopierTemplate[Copier_template]
CopierTemplate -->|render| GenProj[Generated_Rust_project]
Dev -->|make lint| LintTarget[Makefile_lint]
LintTarget --> CargoClippy[cargo_clippy]
LintTarget --> Whitaker[whitaker_lints]
Dev -->|make test| TestTarget[Makefile_test]
TestTarget --> Nextest[cargo_nextest_run]
GenProj -->|local_build| CargoConfig[.cargo_config_cranelift_mold]
CI[GitHub_Actions_CI] -->|run make all| GenProj
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3b94065abc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@AGENTS.md`:
- Line 55: In AGENTS.md update the example command that uses an invalid git
option: replace the substring "git branch --show" with "git branch
--show-current" in the tee pipeline so the documented command becomes runnable;
ensure the rest of the line (the make test and tee usage) remains unchanged and
the updated example appears where the original command is shown.
In `@docs/execplans/rust-project-enhancements.md`:
- Around line 120-121: Remove or update the stale statement "The branch
currently points at the same commit as `main`" so it no longer contradicts later
progress entries; replace it with a short line that reflects the actual
committed/pushed state recorded later in the document (e.g., "Branch advanced
and changes committed/pushed as recorded below") ensuring the execution log
remains temporally consistent with subsequent entries and preserving the
original tone and formatting.
In `@template/.github/workflows/ci.yml`:
- Around line 21-27: The CI installs mold in the "Install mold linker" step but
the coverage job explicitly forces clang to use lld via -fuse-ld=lld, which is
confusing; update the repo to explicitly state and enforce this behavior: add a
short comment in the CI step clarifying that mold is installed for faster dev
builds while coverage uses lld for llvm-tools compatibility, ensure both mold
and lld remain installed in that step, and update the Makefile (e.g., the
default build target and the coverage target) so the default uses mold but the
coverage target sets RTFLAGS/CFLAGS/LDFLAGS to -fuse-ld=lld; also update the
README/docs to document that dev builds use mold and coverage generation
requires lld.
In `@template/Cargo.toml.jinja`:
- Around line 15-21: Add a short comment above the [package.metadata.binstall]
block in Cargo.toml.jinja explaining that the pkg-url string intentionally mixes
Jinja2 ({{ repository_url }}, {{ package_name }}) rendered at project generation
with single-brace placeholders ({ version }, { target }, { binary-ext }) which
are cargo-binstall variables substituted at install time; reference the pkg-url
key and the package.metadata.binstall section so future maintainers understand
the dual-template semantics.
In `@tests/test_template.py`:
- Around line 83-84: Update the two bare assertions in the test that check for
the created files—specifically the checks asserting (project / "src" /
"lib.rs").exists() and asserting not (project / ".github" / "workflows" /
"release.yml").exists()—to include descriptive assertion messages; replace each
bare assert with assert <condition>, "<clear message describing expected
condition and context>" so failures show which file existence check failed and
why (e.g., "expected lib.rs to exist in project src" and "expected release.yml
workflow not to be present").
- Around line 69-70: The two bare assertions in tests/test_template.py should
include descriptive failure messages: replace the assertions that check (project
/ "src" / "main.rs").exists() and (project / ".github" / "workflows" /
"release.yml").exists() with assertions that provide clear messages (e.g.,
indicating the missing file path or that project scaffolding failed) so test
failures print helpful context; update the two asserts to use the form assert
<condition>, "<descriptive message>" referring to those exact expressions.
- Line 96: Update the bare assertion in tests/test_template.py that currently
reads assert (project / "Makefile").exists() to include a descriptive message;
change the assertion for the expression (project / "Makefile").exists() to use
the assert ... , "message" form (e.g., include which project path or that the
Makefile is missing) so failures show a clear diagnostic instead of a silent
bare-assert failure.
- Around line 55-56: Replace the two bare asserts in tests/test_template.py with
assertions that include descriptive messages: for the Cargo manifest check,
update the assertion that calls (project / "Cargo.toml").exists() to include a
message like "expected Cargo.toml to exist in project root", and for the library
source check, update the assertion that calls (project / "src" /
f"{LIB}.rs").exists() to include a message like "expected src/{LIB}.rs to
exist"; locate and modify the two assertions referencing (project /
"Cargo.toml").exists() and (project / "src" / f"{LIB}.rs").exists() to add the
respective ", \"message\"" argument.
- Around line 1-13: Add a module-level triple-quoted docstring immediately after
the `from __future__ import annotations` line that explains this test suite's
purpose (validating the Copier Rust template with pytest-copier), how to use it
(e.g., run tests with `uvx pytest`), and notes about the key fixtures/variables
used (`CopierFixture`, `CopierProject`, `TEMPLATE_PATH`, `APP`, `LIB`) so future
readers understand intent and usage.
- Around line 146-168: Update every bare assert in tests/test_template.py (the
ones referencing cargo_toml, makefile, cargo_config, rust_toolchain,
ci_workflow, test_stub, and the APP/flavour conditional with release_workflow)
to include a descriptive message using the assert <condition>, "message" form;
for example describe what each contract checks like "Cargo.toml must include
description", "Makefile must invoke nextest", "Cargo config must enable
cranelift", "Rust toolchain must include llvm-tools-preview", "CI workflow must
cache Whitaker", "Test stub must include deletion note", and for the APP branch
messages such as "Binstall metadata must be present in Cargo.toml" and "Release
workflow must pin upload-artifact action". Ensure every assert in that block
gets a clear one-line message.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 61e25630-f08f-4c54-bb74-5b01163db70f
📒 Files selected for processing (14)
.github/workflows/ci.ymlAGENTS.mdcopier.yamldocs/execplans/rust-project-enhancements.mdtemplate/.cargo/config.toml.jinjatemplate/.github/workflows/ci.ymltemplate/.github/workflows/{% if flavour == 'app' %}release.yml{% endif %}.jinjatemplate/.github/workflows/{% if flavour == APP %}release.yml{% endif %}.jinjatemplate/Cargo.toml.jinjatemplate/Makefile.jinjatemplate/rust-toolchain.toml.jinjatemplate/src/{% if flavour == 'app' %}main.rs{% else %}lib.rs{% endif %}.jinjatemplate/tests/stub.rstests/test_template.py
💤 Files with no reviewable changes (2)
- template/.github/workflows/{% if flavour == APP %}release.yml{% endif %}.jinja
- .github/workflows/ci.yml
Replace the shared coverage action in the parent repository workflow with the supported make test target. Remove the dependent CodeScene upload because the parent template test target does not produce lcov output.
Limit pytest-copier's temporary template repository to the actual Copier inputs so CI does not copy the pull request checkout's .git directory. This avoids detached merge metadata making the fixture's synthetic git commit a no-op.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tests/conftest.py`:
- Around line 1-4: Add a module-level triple-quoted docstring immediately after
the "from __future__ import annotations" line that explains that this
tests.conftest module provides pytest fixtures used to configure pytest-copier's
template input selection during test runs, describes its purpose and basic usage
(how the fixtures affect template selection), and gives a short example of how a
test should reference those fixtures; ensure the docstring is placed at the top
of the module before any other imports or code.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 41c56e28-0587-450d-ad2d-2934ac4b4c89
📒 Files selected for processing (1)
tests/conftest.py
Add a module docstring to tests.conftest explaining why pytest-copier only copies the actual Copier template inputs and how tests consume that fixture through the normal copier fixture.
Install mold, nextest, mbake, and Whitaker in the parent CI workflow so pytest-copier can run generated make all gates on GitHub runners. Also install nextest in rendered CI and fix the generated lib Makefile doctest recipe indentation.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/conftest.py (1)
18-21: 🧹 Nitpick | 🔵 Trivial | 💤 Low valueExpand fixture docstring to full numpy style.
The guideline requires full structured documentation for all public interfaces. A pytest fixture in conftest.py is a public interface within the test suite. Add a Returns section following numpy style.
📚 Proposed enhancement to use numpy-style docstring
`@pytest.fixture`(scope="session") def copier_template_paths() -> list[str]: - """Copy only template inputs into pytest-copier's temporary Git repo.""" + """ + Copy only template inputs into pytest-copier's temporary Git repo. + + Returns + ------- + list[str] + File paths to include in the temporary repository, relative to + the repository root. + """ return ["copier.yaml", "template"]As per coding guidelines: "Use a single-line summary for private functions and methods, and full structured docs for all public interfaces."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/conftest.py` around lines 18 - 21, Expand the docstring for the public pytest fixture copier_template_paths to a full numpy-style docstring: include a short summary line, a blank line, a Parameters section (if applicable) and a Returns section that documents the return type as list[str] and describes that it returns the file/directory names to copy into pytest-copier's temporary Git repo; update the triple-quoted string above the function copier_template_paths accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@tests/conftest.py`:
- Around line 18-21: Expand the docstring for the public pytest fixture
copier_template_paths to a full numpy-style docstring: include a short summary
line, a blank line, a Parameters section (if applicable) and a Returns section
that documents the return type as list[str] and describes that it returns the
file/directory names to copy into pytest-copier's temporary Git repo; update the
triple-quoted string above the function copier_template_paths accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 860a930e-558c-4aaa-bce3-68a38516706e
📒 Files selected for processing (1)
tests/conftest.py
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Pin parent workflow actions to full commit SHAs and use the requested shared-actions revision for the parent Rust setup action. Document the template test module and helper contracts, then add explicit failure messages to generated-project assertions.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Restore the generated Makefile fallback to `cargo test` when `cargo-nextest` is unavailable, and assert the fallback contract in the template tests. Parse generated `Cargo.toml` as TOML so metadata prompts and app binstall fields are covered by exact structured assertions.
|
@coderabbitai pause |
✅ Actions performedReviews paused. |
Explain that the generated `pkg-url` combines Copier-rendered Jinja2 values with cargo-binstall placeholders expanded later during install.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Resolve the generated Makefile dry-run through an absolute make path, construct synthetic PATH values portably, and split the large tooling contract test into focused assertion helpers. Also fix the README article before lld-backed.
|
@coderabbitai Have the following now been resolved? tests/test_template.py (1)
♻️ Refactor outline+def assert_cargo_contracts(package: dict[str, object], metadata: dict[str, object], flavour: str) -> None:
+ ...
+
+def assert_makefile_contracts(makefile: str) -> None:
+ ...
+
+def assert_ci_contracts(ci_workflow: str, parsed_ci_workflow: dict[str, object]) -> None:
+ ...
+
+def assert_toolchain_contracts(cargo_config: str, rust_toolchain: str, dev_target: str) -> None:
+ ...
+
+def assert_release_contracts(project: CopierProject, metadata: dict[str, object], flavour: str) -> None:
+ ...
+
def test_generated_tooling_contracts(...):
- # 70+ statements and mixed responsibilities
+ project = render_project(...)
+ ...
+ assert_cargo_contracts(package, metadata, flavour)
+ assert_makefile_contracts(makefile)
+ assert_ci_contracts(ci_workflow, parsed_ci_workflow)
+ assert_toolchain_contracts(cargo_config, rust_toolchain, dev_target)
+ assert_release_contracts(project, metadata, flavour)As per coding guidelines: "Keep C90 / mccabe complexity ≤ 9" and "Follow single responsibility and CQRS (command/query segregation)". 🤖 Detailed instructionsVerify each finding against current code. Fix only still-valid issues, skip the In ♻️ Duplicate comments (1)README.md (1)
📝 Proposed fix- fallback, Whitaker linting, and an lld-backed coverage target.
+ fallback, Whitaker linting, and a lld-backed coverage target.🤖 Detailed instructionsVerify each finding against current code. Fix only still-valid issues, skip the In |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 2589
All required helpers are present and
The orchestrating function now calls these helpers directly after reading the generated files.
The line now reads: |
Add explicit parsing context for generated files, exercise Whitaker fallback behaviour through real Makefile execution, and snapshot generated structured tooling files. Log Whitaker and coverage linker diagnostics in generated workflows and Makefiles, and document the new snapshot test dependency.
Explain why the generated release workflow clears repository Rust flags before installing cross and why release builds explicitly use the stable toolchain.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Format the syrupy dependency name in the developer guide, make the lint subprocess non-raising behaviour explicit, and add a diagnostic message to the generated structured file snapshot assertion.
Link the app stub lint expectation to the tracked tooling plan, add root CI Whitaker diagnostics, and consolidate generated tooling contract assertions into one validator.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Wrap PyYAML and Whitaker in inline code formatting so the tooling list is consistent with the surrounding entries.
|
@coderabbitai please create a new GitHub issue for the following: Testing (Compile-Time / Ui) | |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain
🏁 Script executed: Length of output: 56
|
Extract the GitHub Actions checkout step selection into a helper and reuse it for generated CI and release workflow contract checks.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/test_template.py (1)
381-435: 🧹 Nitpick | 🔵 Trivial | ⚖️ Poor tradeoffSplit this validator into thematic sub-helpers to reduce statement density.
The static analysis correctly flags 64 statements exceeding the 50-statement threshold. Extract themed assertion groups into private helpers:
_assert_cargo_package_contracts(...)for lines 397–435_assert_makefile_contracts(...)for lines 437–466_assert_cargo_config_contracts(...)for lines 468–485_assert_ci_workflow_contracts(...)for lines 494–538_assert_release_workflow_contracts(...)for lines 551–577Each sub-helper receives only the parameters it requires, improving testability and localising future changes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/test_template.py` around lines 381 - 435, The assert_generated_tooling_contracts function is too large; split its assertion blocks into focused private helpers and call them from assert_generated_tooling_contracts. Create _assert_cargo_package_contracts(package, metadata, flavour), _assert_makefile_contracts(makefile), _assert_cargo_config_contracts(cargo_config), _assert_ci_workflow_contracts(parsed_ci_workflow, ci_workflow, test_stub), and _assert_release_workflow_contracts(release_workflow) and move the corresponding themed assertions into each helper (retaining checks for binstall inside _assert_cargo_package_contracts using flavour), then update assert_generated_tooling_contracts to call these helpers with only the parameters they need.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@tests/test_template.py`:
- Around line 381-435: The assert_generated_tooling_contracts function is too
large; split its assertion blocks into focused private helpers and call them
from assert_generated_tooling_contracts. Create
_assert_cargo_package_contracts(package, metadata, flavour),
_assert_makefile_contracts(makefile),
_assert_cargo_config_contracts(cargo_config),
_assert_ci_workflow_contracts(parsed_ci_workflow, ci_workflow, test_stub), and
_assert_release_workflow_contracts(release_workflow) and move the corresponding
themed assertions into each helper (retaining checks for binstall inside
_assert_cargo_package_contracts using flavour), then update
assert_generated_tooling_contracts to call these helpers with only the
parameters they need.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 44ccbd69-3af3-4261-bdc9-dbf9a9bf47b2
📒 Files selected for processing (4)
.github/workflows/ci.ymldocs/developers-guide.mdtemplate/src/{% if flavour == 'app' %}main.rs{% else %}lib.rs{% endif %}.jinjatests/test_template.py
|
@coderabbitai Have the following now been resolved? tests/test_template.py (1)
♻️ Proposed extractiondef extract_checkout_steps(jobs: dict[str, Any]) -> list[dict[str, Any]]:
"""Extract checkout steps from workflow jobs."""
return [
step
for job in jobs.values()
if isinstance(job, dict)
for step in job.get("steps", [])
if isinstance(step, dict)
and step.get("uses", "").startswith("actions/checkout@")
]🤖 Detailed instructionsVerify each finding against current code. Fix only still-valid issues, skip the In |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 3134
The raw list comprehension no longer appears in either location. |
Move the dense generated tooling validator into focused private assertion helpers while preserving the existing checks and failure messages.
|
@coderabbitai Have the following now been resolved? tests/test_template.py (1)
🤖 Detailed instructionsVerify each finding against current code. Fix only still-valid issues, skip the In tests/test_template.py (2)
🤖 Detailed instructionsVerify each finding against current code. Fix only still-valid issues, skip the In
🤖 Detailed instructionsVerify each finding against current code. Fix only still-valid issues, skip the In |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 8440 🏁 Script executed: Length of output: 1397
Module docstring ( NumPy-style structured docstrings ( Descriptive failure messages on bare |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/test_template.py (1)
411-579: 🛠️ Refactor suggestion | 🟠 Major | 🏗️ Heavy liftSplit this test module to enforce the 400-line limit.
Move parsing helpers and tooling-contract assertion helpers into dedicated support modules and keep this file focused on scenario-level tests. The current module exceeds the maximum logical line count and bundles too many responsibilities in one place.
As per coding guidelines, "Files must not exceed 400 logical lines: Decompose large modules into subpackages".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/test_template.py` around lines 411 - 579, This test module exceeds the 400-line limit; extract the parsing helpers and tooling-assertion helpers into dedicated support modules and keep only scenario-level tests here. Create a new support module (e.g., tests/support/tooling_asserts.py) and move helper functions such as _assert_cargo_package_contracts, _assert_makefile_contracts, _assert_cargo_config_contracts, _assert_ci_workflow_contracts and any parsing helpers they depend on into it, update imports in tests/test_template.py to import those helpers, and ensure all references (function names and any utility helpers like require_mapping or extract_checkout_steps) are updated and tests still import only scenario-level fixtures and calls. Ensure tests/test_template.py remains focused on high-level scenarios and falls below 400 logical lines after relocation.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@tests/test_template.py`:
- Around line 411-579: This test module exceeds the 400-line limit; extract the
parsing helpers and tooling-assertion helpers into dedicated support modules and
keep only scenario-level tests here. Create a new support module (e.g.,
tests/support/tooling_asserts.py) and move helper functions such as
_assert_cargo_package_contracts, _assert_makefile_contracts,
_assert_cargo_config_contracts, _assert_ci_workflow_contracts and any parsing
helpers they depend on into it, update imports in tests/test_template.py to
import those helpers, and ensure all references (function names and any utility
helpers like require_mapping or extract_checkout_steps) are updated and tests
still import only scenario-level fixtures and calls. Ensure
tests/test_template.py remains focused on high-level scenarios and falls below
400 logical lines after relocation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: c9bb09fe-f009-4659-8f54-4ab42723f3a5
📒 Files selected for processing (1)
tests/test_template.py
|
@coderabbitai please create a new GitHub issue for the following: Please address the following concerns and ensure all commit gates succeed:
|
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain
🏁 Script executed: Length of output: 56
It covers splitting |
1 participant
Summary
This branch imports the requested Rust project tooling into the Copier template so generated projects use fast local Rust iteration, stricter linting, release metadata, and template tests that exercise the generated public gates.
Execplan: docs/execplans/rust-project-enhancements.md
Review walkthrough
Validation
make test 2>&1 | tee /tmp/test-agent-template-rust-rust-project-enhancements-tooling-import.out: passed, 9 tests.make test 2>&1 | tee /tmp/test-agent-template-rust-rust-project-enhancements-final.out: passed, 9 tests.coderabbit review --agent 2>&1 | tee /tmp/coderabbit-agent-template-rust-rust-project-enhancements-tooling-import.out: actionable findings were addressed. One later recommendation to replace action SHAs with version tags was intentionally not applied because the task explicitly required replacing versions with SHAs sourced through Firecrawl-assisted lookup.Notes
The root AGENTS.md now states that this repository is a Copier template and documents how to run pytest-copier tests through
uvx.Summary by Sourcery
Import Rust template tooling into the Copier template so generated Rust projects include the requested metadata, tooling contracts, and CI behaviour, and ensure template tests validate these public gates.
New Features:
Enhancements:
CI: