Conversation
Export `CARGO_PROFILE_DEV_CODEGEN_BACKEND=llvm` and `CARGO_PROFILE_TEST_CODEGEN_BACKEND=llvm` for Cranelift-configured projects so `cargo llvm-cov` child cargo processes inherit the LLVM backend. Remove the outer `cargo --config ... codegen-backend=\"llvm\"` workaround, add fixture-backed regression coverage, and document the behaviour in the action changelog and README.
Add repository-aware toolchain resolution for `rust-build-release` so the composite action prefers an explicit `toolchain` input, then repo `rust-toolchain.toml` or `rust-toolchain`, then manifest `rust-version`, and only falls back to the bundled `TOOLCHAIN_VERSION`. Pass the resolved toolchain through the action setup step using the target `project-dir`, add nightly-plus-Cranelift fixture coverage, and keep the explicit override path from forcing an early manifest lookup.
Reviewer's GuideExtends the rust-build-release and generate-coverage GitHub Actions to resolve Rust toolchains from the target repository (toolchain override, rust-toolchain*, Cargo.toml rust-version, then bundled default) and to handle Cranelift projects by forcing LLVM codegen via cargo environment variables instead of --config flags, updating CLIs, action.yml, main logic, and tests/fixtures accordingly. Flow diagram for resolving requested Rust toolchainflowchart TD
Start((Start)) --> CheckExplicit
CheckExplicit{"Explicit toolchain<br/>input provided?"}
CheckExplicit -->|Yes| UseExplicit
CheckExplicit -->|No| ResolveRepoToolchain
UseExplicit["Use trimmed explicit<br/>toolchain input"] --> End
ResolveRepoToolchain{"rust-toolchain.toml or<br/>rust-toolchain found and<br/>parseable in search dirs?"}
ResolveRepoToolchain -->|Yes| UseRepoToolchain
ResolveRepoToolchain -->|No| CheckManifestRustVersion
UseRepoToolchain["Use channel from<br/>nearest rust-toolchain*<br/>file"] --> End
CheckManifestRustVersion{"Cargo manifest or workspace<br/>declares rust-version?"}
CheckManifestRustVersion -->|Yes| UseManifestRustVersion
CheckManifestRustVersion -->|No| UseFallback
UseManifestRustVersion["Use rust-version from<br/>package or workspace.package"] --> End
UseFallback["Use bundled fallback<br/>default toolchain"] --> End
End(("Resolved<br/>toolchain"))
Flow diagram for coverage command env and Cranelift handlingflowchart TD
Start((Start coverage
workflow)) --> DetectCranelift
DetectCranelift["_uses_cranelift_backend:
inspect .cargo/config.toml
for Cranelift settings"]
DetectCranelift -->|Cranelift enabled| SetEnv
DetectCranelift -->|Cranelift not enabled| NoExtraEnv
SetEnv["get_cargo_coverage_env:
return { CARGO_PROFILE_DEV_CODEGEN_BACKEND=llvm,
CARGO_PROFILE_TEST_CODEGEN_BACKEND=llvm }"] --> BuildArgs
NoExtraEnv["get_cargo_coverage_env:
return {}"] --> BuildArgs
BuildArgs["get_cargo_coverage_cmd:
construct ['llvm-cov', 'nextest'? ...]
(no --config profile.*.codegen-backend overrides)"] --> RunMainCargo
RunMainCargo["_run_cargo(args, extra_env):
- prefix command echo with KEY=VALUE
- run cargo with extra_env merged
into environment"] --> OptionalCucumber
OptionalCucumber{"with_cucumber_rs
enabled and features set?"}
OptionalCucumber -->|No| End
OptionalCucumber -->|Yes| RunCucumber
RunCucumber["run_cucumber_rs_coverage:
- build cucumber.rs args
- call _run_cargo(c_args, extra_env)"] --> End
End((Coverage
complete))
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Note Reviews pausedUse the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughExtended two GitHub Actions with Rust toolchain resolution capabilities. The Changes
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 3❌ Failed checks (3 warnings)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
![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: b857f546d1
ℹ️ 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: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/actions/generate-coverage/scripts/run_rust.py:
- Around line 160-164: The _uses_cranelift_backend helper currently only checks
.cargo/config(.toml) so update _uses_cranelift_backend(manifest_path: Path) to
also open and parse the project Cargo.toml (manifest_path) and inspect
[profile.dev] and [profile.test] for a codegen-backend = "cranelift" entry
(handle TOML booleans/strings and whitespace/casing), returning True if found so
get_cargo_coverage_env() will return the LLVM override; add a unit test that
creates a manifest-only project with codegen-backend set under [profile.dev] or
[profile.test] and asserts the helper detects cranelift (and that
get_cargo_coverage_env() yields the expected env override).
In @.github/actions/rust-build-release/src/main.py:
- Around line 299-314: The function _fallback_toolchain_name repeats startswith
checks; simplify by replacing the two separate startswith checks with a single
startswith call that accepts a tuple (channel_prefix, dotted_prefix) to reduce
duplication while keeping the same matching logic for names in installed_names
and preserving the exact behavior for the equality check (name == toolchain) and
the generator expression returned by next.
- Around line 215-222: The loop checking installed_names uses two separate
startswith calls; simplify the condition by combining them into a single tuple
startswith check: keep the equality check (name == toolchain) and replace
"name.startswith(channel_prefix) or name.startswith(dotted_prefix)" with
"name.startswith((channel_prefix, dotted_prefix))" so the if becomes "if (name
== toolchain or name.startswith((channel_prefix, dotted_prefix))): return name";
update the block around dotted_prefix, installed_names, channel_prefix
accordingly.
In @.github/actions/rust-build-release/src/toolchain.py:
- Around line 46-53: The fallback that treats any malformed TOML as a legacy
channel string is too permissive; in _parse_toolchain_file, when
tomllib.TOMLDecodeError is caught, first check the Path object's filename
(path.name) and return None unless it equals "rust-toolchain" so only legacy
non-TOML rust-toolchain files are parsed line-by-line for a channel; otherwise
skip the fallback and return None.
- Around line 62-82: The toolchain search can climb above the checked-out
project root and pick up unrelated parent rust-toolchain files; update
_iter_toolchain_search_dirs to accept a stop_at Path (repo_root), resolve both
start and stop_at, return immediately if start is not inside repo_root, and stop
traversal when search_dir == repo_root or when a .git directory is found; then
update read_repo_toolchain to call
_iter_toolchain_search_dirs(resolved_manifest.parent, project_dir) so discovery
is bounded to the repo root.
In @.github/actions/rust-build-release/tests/test_manifest_path.py:
- Around line 315-317: The test stub function fake_cargo has an unused parameter
named target_arg which triggers ARG001; rename target_arg to _target_arg in the
fake_cargo signature to mark it as intentionally unused (update the parameter
name in the def fake_cargo(_spec: str, _target_arg: str, manifest_arg: Path,
features_arg: str) declaration and any local references if present) to silence
Ruff.
- Around line 300-324: The test test_main_prefers_repo_declared_toolchain relies
on ambient RBR_MANIFEST_PATH; before changing directory and invoking
main_module.main("aarch64-unknown-linux-gnu") clear that env var so the test
uses NIGHTLY_CRANELIFT_PROJECT/Cargo.toml: add
monkeypatch.delenv("RBR_MANIFEST_PATH", raising=False) near the top of the test
(before monkeypatch.chdir(NIGHTLY_CRANELIFT_PROJECT)) so _resolve_manifest in
main_module.main cannot pick up an external manifest.
🪄 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
Run ID: 720cdf54-390b-4b57-bf5b-6b522c579d5d
📒 Files selected for processing (20)
.github/actions/generate-coverage/CHANGELOG.md.github/actions/generate-coverage/README.md.github/actions/generate-coverage/scripts/run_rust.py.github/actions/generate-coverage/tests/fixtures/nightly-cranelift-project/.cargo/config.toml.github/actions/generate-coverage/tests/fixtures/nightly-cranelift-project/Cargo.toml.github/actions/generate-coverage/tests/fixtures/nightly-cranelift-project/rust-toolchain.toml.github/actions/generate-coverage/tests/test_scripts.py.github/actions/rust-build-release/CHANGELOG.md.github/actions/rust-build-release/README.md.github/actions/rust-build-release/action.yml.github/actions/rust-build-release/src/action_setup.py.github/actions/rust-build-release/src/main.py.github/actions/rust-build-release/src/toolchain.py.github/actions/rust-build-release/tests/fixtures/nightly-cranelift-project/.cargo/config.toml.github/actions/rust-build-release/tests/fixtures/nightly-cranelift-project/Cargo.toml.github/actions/rust-build-release/tests/fixtures/nightly-cranelift-project/rust-toolchain.toml.github/actions/rust-build-release/tests/test_action_setup.py.github/actions/rust-build-release/tests/test_manifest_input_step.py.github/actions/rust-build-release/tests/test_manifest_path.py.github/actions/rust-build-release/tests/test_toolchain_helpers.py
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Bumpy Road Ahead.github/actions/rust-build-release/src/toolchain.py: read_manifest_rust_version What lead to degradation?read_manifest_rust_version has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function Why does this problem occur?A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health. How to fix it?Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the Bumpy Road code health issue. |
|
@coderabbitai pause |
✅ Actions performedReviews paused. |
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Bumpy Road Ahead.github/actions/rust-build-release/src/toolchain.py: _parse_toolchain_file What lead to degradation?_parse_toolchain_file has 2 blocks with nested conditional logic. Any nesting of 2 or deeper is considered. Threshold is 2 blocks per function Why does this problem occur?A Bumpy Road is a function that contains multiple chunks of nested conditional logic inside the same function. The deeper the nesting and the more bumps, the lower the code health. How to fix it?Bumpy Road implementations indicate a lack of encapsulation. Check out the detailed description of the Bumpy Road code health issue. |
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Complex Conditional.github/actions/rust-build-release/src/main.py: _resolve_toolchain_name What lead to degradation?_resolve_toolchain_name has 1 complex conditionals with 2 branches, threshold = 2 Why does this problem occur?A complex conditional is an expression inside a branch such as an if-statmeent which consists of multiple, logical operations. Example: if (x.started() && y.running()).Complex conditionals make the code even harder to read, and contribute to the Complex Method code smell. Encapsulate them. How to fix it?Apply the DECOMPOSE CONDITIONAL refactoring so that the complex conditional is encapsulated in a separate function with a good name that captures the business rule. Optionally, for simple expressions, introduce a new variable which holds the result of the complex conditional. Helpful refactoring examplesTo get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes. SAMPLE# complex_conditional.js
function messageReceived(message, timeReceived) {
- // Ignore all messages which aren't from known customers:
- if (!message.sender &&
- customers.getId(message.name) == null) {
+ // Refactoring #1: encapsulate the business rule in a
+ // function. A clear name replaces the need for the comment:
+ if (!knownCustomer(message)) {
log('spam received -- ignoring');
return;
}
- // Provide an auto-reply when outside business hours:
- if ((timeReceived.getHours() > 17) ||
- (timeReceived.getHours() < 8)) {
+ // Refactoring #2: encapsulate the business rule.
+ // Again, note how a clear function name replaces the
+ // need for a code comment:
+ if (outsideBusinessHours(timeReceived)) {
return autoReplyTo(message);
}
pingAgentFor(message);
+}
+
+function outsideBusinessHours(timeReceived) {
+ // Refactoring #3: replace magic numbers with
+ // symbols that communicate with the code reader:
+ const closingHour = 17;
+ const openingHour = 8;
+
+ const hours = timeReceived.getHours();
+
+ // Refactoring #4: simple conditional rules can
+ // be further clarified by introducing a variable:
+ const afterClosing = hours > closingHour;
+ const beforeOpening = hours < openingHour;
+
+ // Yeah -- look how clear the business rule is now!
+ return afterClosing || beforeOpening;
} |
This comment was marked as resolved.
This comment was marked as resolved.
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Complex Method.github/actions/generate-coverage/scripts/run_rust.py: _run_cargo What lead to degradation?_run_cargo increases in cyclomatic complexity from 11 to 13, threshold = 9 Why does this problem occur?A Complex Method has a high cyclomatic complexity. The recommended threshold for the Python language is a cyclomatic complexity lower than 9. How to fix it?There are many reasons for Complex Method. Sometimes, another design approach is beneficial such as a) modeling state using an explicit state machine rather than conditionals, or b) using table lookup rather than long chains of logic. In other scenarios, the function can be split using EXTRACT FUNCTION. Just make sure you extract natural and cohesive functions. Complex Methods can also be addressed by identifying complex conditional expressions and then using the DECOMPOSE CONDITIONAL refactoring. Helpful refactoring examplesTo get a general understanding of what this code health issue looks like - and how it might be addressed - we have prepared some diffs for illustrative purposes. SAMPLE# complex_method.js
function postItem(item) {
if (!item.id) {
- if (item.x != null && item.y != null) {
- post(item);
- } else {
- throw Error("Item must have x and y");
- }
+ // extract a separate function for creating new item
+ postNew(item);
} else {
- if (item.x < 10 && item.y > 25) {
- put(item);
- } else {
- throw Error("Item must have an x and y value between 10 and 25");
- }
+ // and one for updating existing items
+ updateItem(item);
}
}
+
+function postNew(item) {
+ validateNew(item);
+ post(item);
+}
+
+function updateItem(item) {
+ validateUpdate(item);
+ put(item);
+}
+ |
This comment was marked as resolved.
This comment was marked as resolved.
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Excess Number of Function Arguments.github/actions/rust-build-release/tests/test_manifest_path.py: test_main_prefers_repo_declared_toolchain What lead to degradation?test_main_prefers_repo_declared_toolchain has 5 arguments, max arguments = 4 Why does this problem occur?Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments. How to fix it?Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept. |
This comment was marked as resolved.
This comment was marked as resolved.
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Excess Number of Function Arguments.github/actions/rust-build-release/src/action_setup.py: toolchain What lead to degradation?toolchain has 5 arguments, max arguments = 4 Why does this problem occur?Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments. How to fix it?Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
@coderabbitai Have the following failed checks now been resolved? If further work is required, please provide an AI agent prompt for the remaining work to be done to address these failures. ❌ Failed checks (3 warnings, 1 inconclusive)
|
This comment was marked as resolved.
This comment was marked as resolved.
Extract the default-toolchain lookup and the runner-specific resolution into dedicated helpers above the `toolchain` CLI entry point. Keep the CLI surface unchanged while reducing the command's argument count and separating the override/manifest lookup from the runner-mapping step.
Split `_run_cargo` into focused private helpers for cargo command construction, missing-stream abort handling, and process wait/error handling. Preserve the observable behaviour while lowering the function's cyclomatic complexity and keeping the existing output and exit paths.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Replace the individual `main()` wiring fixtures in `test_main_prefers_repo_declared_toolchain` with the existing `build_main_context` bundle. Keep the assertions and behaviour unchanged while reducing the test function's argument count to the required threshold.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Factor the repeated channel-prefix predicate out of `_resolve_toolchain_name` and `_fallback_toolchain_name` into a single private helper in `main.py`. Keep the existing resolution behaviour unchanged while reducing the complexity of the duplicated conditional logic.
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. .github/actions/rust-build-release/tests/test_action_setup.py Comment on lines +281 to +305 def test_cli_toolchain_prefers_repo_declared_nightly(
action_setup_module: ModuleType,
monkeypatch: pytest.MonkeyPatch,
) -> None:
"""Repo toolchain files override the action fallback when no input is set."""
monkeypatch.chdir(NIGHTLY_CRANELIFT_PROJECT)
result = runner.invoke(
action_setup_module.app,
[
"toolchain",
"--target",
"aarch64-unknown-linux-gnu",
"--manifest-path",
"Cargo.toml",
"--runner-os",
"Linux",
"--runner-arch",
"X64",
],
prog_name="action-setup",
)
assert result.exit_code == 0
assert result.stdout.strip() == "nightly-2026-03-26"❌ New issue: Code Duplication |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Bound repository toolchain discovery with an optional `stop_at` limit and cover the inclusive boundary behaviour in the helper tests. Extract manifest-side Cranelift detection into a private helper, keep the existing tolerant matching for profile values, and add fixture-backed coverage for manifest-only `Cargo.toml` profile declarations.
Document that the `generate-coverage` action scans `.cargo/config.toml`, `.cargo/config`, and `Cargo.toml` profile settings when deciding whether to export the LLVM codegen backend overrides for coverage runs.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Document the internal toolchain-resolution flow in `rust-build-release` and the Cranelift coverage override path in `generate-coverage`. Also add brief contributor guidance for fixtures, changelog updates, and README expectations when introducing new actions.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Remove duplicated `_run_cargo` stubbing from the two cucumber coverage environment-propagation tests in `test_scripts.py`. Keep the assertions and execution path unchanged while moving the shared setup into a private helper.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Replace the two structurally identical nightly-project CLI toolchain tests in `test_action_setup.py` with a single parameterized test. Keep both behaviors covered and preserve explicit pytest case IDs for the repo-declared nightly path and the CLI override path.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Excess Number of Function Arguments.github/actions/generate-coverage/tests/test_scripts.py: _run_cucumber_coverage_and_capture_env What lead to degradation?_run_cucumber_coverage_and_capture_env has 5 arguments, max arguments = 4 Why does this problem occur?Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments. How to fix it?Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept. |
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Excess Number of Function Arguments.github/actions/rust-build-release/src/action_setup.py: toolchain What lead to degradation?toolchain has 5 arguments, max arguments = 4 Why does this problem occur?Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments. How to fix it?Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Ensure that this is validated against the current version of the codegraph. If further refinement to address this finding would be deleterious, please supply a clear explanatory one to two paragraph markdown message I can paste into the CodeScene web ui's diagnostic suppression function so this diagnostic can be silenced. Excess Number of Function Arguments.github/actions/generate-coverage/tests/test_scripts.py: _run_cucumber_coverage_and_capture_env What lead to degradation?_run_cucumber_coverage_and_capture_env has 5 arguments, max arguments = 4 Why does this problem occur?Functions with many arguments indicate either a) low cohesion where the function has too many responsibilities, or b) a missing abstraction that encapsulates those arguments. How to fix it?Start by investigating the responsibilities of the function. Make sure it doesn't do too many things, in which case it should be split into smaller and more cohesive functions. Consider the refactoring INTRODUCE PARAMETER OBJECT to encapsulate arguments that refer to the same logical concept. |
This comment was marked as resolved.
This comment was marked as resolved.
Reduce the helper argument count in generate-coverage test scaffolding by bundling the manifest path and extra environment into a private dataclass.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
|
@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Ensure that this is validated against the current version of the codegraph. If further refinement to address this finding would be deleterious, please supply a clear explanatory one to two paragraph markdown message I can paste into the CodeScene web ui's diagnostic suppression function so this diagnostic can be silenced. Number of Functions in a Single Module.github/actions/generate-coverage/tests/test_scripts.py: What lead to degradation?This module has 76 functions, threshold = 75 |
This comment was marked as resolved.
This comment was marked as resolved.
Collapse the four structurally identical zero-coverage LCOV tests into one parametrized test while preserving the per-case pytest ids.
|
@coderabbitai Have the following failed checks now been resolved? If further work is required, please provide an AI agent prompt for the remaining work to be done to address these failures. ❌ Failed checks (3 warnings)
|
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 5427 🏁 Script executed: Length of output: 6199
No further work is required for these three items. |
1 participant
Summary by Sourcery
Resolve Rust toolchains from the target repository for the rust-build-release action and switch Cranelift coverage handling in the generate-coverage action to use environment-based LLVM codegen overrides.
New Features:
Bug Fixes:
Enhancements:
Documentation:
Tests: