chore: Improved test efficiency

[dev-jodee]

• Added debug make commands to not quiet the output
• Parallel testing and debug

---

Important

Improved test efficiency by enabling parallel testing and adding debug commands in GitHub Actions and Makefiles.

• GitHub Actions:
  • Split rust.yml workflow into separate jobs for build-and-lint, unit-tests, integration-tests, and coverage-report.
  • Added parallel execution for integration tests using a matrix strategy in rust.yml.
  • Updated coverage badge logic in rust.yml to reflect new coverage percentage.
• Makefiles:
  • Added DEBUG.makefile and DEBUG_COMMANDS.makefile for verbose test execution with debug logging.
  • Updated Makefile to include debug test commands.
  • Modified RUST_TESTS.makefile to run integration tests in parallel.
  • Added new targets in UTILS.makefile for starting and stopping parallel test servers.

^{This description was created by for 8a8a9ff. You can customize this summary. It will automatically update as commits are pushed.}

---

📊 Test Coverage

Coverage: 26.3%

View Detailed Coverage Report

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 2354d5a in 2 minutes and 22 seconds. Click for details.

• Reviewed 346 lines of code in 8 files
• Skipped 1 files when reviewing.
• Skipped posting 8 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. Makefile:10

• Draft comment:
  Added inclusion of DEBUG_COMMANDS.makefile and extended PHONY targets for debug; naming appears consistent but double‐check that all new targets are intended.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

2. makefiles/BUILD.makefile:2

• Draft comment:
  Specifying '--bin kora' in the install target clarifies which binary to install; ensure that this binary’s name remains unchanged.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

3. makefiles/BUILD.makefile:27

• Draft comment:
  The 'build-tk' and 'run-presigned' targets have been removed; confirm these functionalities are no longer needed.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. makefiles/CLIENT.makefile:3

• Draft comment:
  Refactored 'gen-ts-client' to depend on the 'openapi' target and updated generator options; verify that the 'openapi' target correctly generates the spec.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

5. makefiles/DEBUG.makefile:18

• Draft comment:
  Using 'killall' in the debug_cleanup function may be too broad and could affect unintended processes; consider adding safeguards or using more specific process identifiers.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The killall commands are actually quite specific - they target exact process names, not patterns. The '|| true' makes them safe by ignoring failures. This is a debug makefile specifically for test execution, so cleaning up test processes is appropriate. The comment seems overly cautious without strong evidence of a real problem. The comment raises a valid general concern about process management. There could be legitimate kora or solana-test-validator processes running that shouldn't be killed. Since this is explicitly a debug test makefile, killing test processes is expected behavior. The process names are exact matches and failures are handled safely. The comment should be deleted as it raises theoretical concerns without strong evidence of actual issues, and the current implementation is appropriate for a debug test makefile.

6. makefiles/RUST_TESTS.makefile:29

• Draft comment:
  The integration tests now run in parallel with a fixed 'sleep 8' pause; ensure that this delay is sufficient in all environments or consider making it configurable.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment raises a valid concern about reliability - a fixed sleep time might not work in all environments. However, this feels like a speculative issue ("ensure that this delay is sufficient") rather than a concrete problem. There's no evidence that 8 seconds isn't enough. The comment is asking for verification rather than pointing out a clear issue. The sleep delay could potentially cause flaky tests in some environments, which would be a real problem. Making it configurable would add flexibility. While the suggestion has merit, per our rules we should not keep comments that ask for verification or raise speculative issues. We need evidence of an actual problem before commenting. Delete the comment since it's speculative and asks for verification without evidence of an actual problem. If test flakiness occurs due to the sleep time, that would be the time to address it.

7. makefiles/UTILS.makefile:160

• Draft comment:
  In 'start_kora_parallel', the use of findstring for 'Multi-Signer' correctly handles dual keys; just confirm that key file paths are always valid in your test setup.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

8. makefiles/UTILS.makefile:172

• Draft comment:
  Using 'pkill -f "kora"' in stop_all_parallel_servers might be overly broad and risk terminating unrelated processes; consider narrowing the match pattern.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment makes a reasonable point about being more specific with process killing. The suggested pattern matches what's used elsewhere in the codebase. However, this is a cleanup function that runs after trying to kill processes by PID, and it's meant to be thorough as a last resort. Being overly specific might actually defeat the purpose of this fallback cleanup mechanism. The comment may be missing the point that this is an intentionally broad cleanup function. The broader pattern might be desirable here as a safety net. The function's purpose is to ensure thorough cleanup of all related processes, so the broader pattern is likely intentional and appropriate in this context. The comment should be deleted because the broad pkill pattern appears to be an intentional design choice for this cleanup function, and making it more specific could reduce its effectiveness as a fallback cleanup mechanism.

Workflow ID: wflow_eSyJLaXupGsD1TtA

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed cd449bb in 1 minute and 49 seconds. Click for details.

• Reviewed 353 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/rust.yml:53

• Draft comment:
  Consider caching the cargo-llvm-cov installation to avoid redundant installs across jobs, which could improve CI performance.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. .github/workflows/rust.yml:138

• Draft comment:
  Ensure matrix.test.setup_multi is compared consistently (as a string or boolean). Explicit conversion might be needed to avoid type mismatch issues in the test environment setup.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

3. .github/workflows/rust.yml:245

• Draft comment:
  Consider adding extra error handling in the PR update script for parsing the lcov file to handle unexpected formats or missing data more robustly.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_9frbua4YAOJK8Vqm

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Add shell error-handling flags (e.g. set -euo pipefail) at the start of the merge coverage reports script to catch errors immediately.

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 8a8a9ff in 1 minute and 10 seconds. Click for details.

• Reviewed 7 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/badges/coverage.json:1

• Draft comment:
  The coverage badge was updated from 86.3% (green) to 26.2% (red), which is a significant drop. Ensure this change accurately reflects the test results following the adjustments to test execution.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% This is a metadata file that automatically gets updated based on test results. The comment is asking for verification, which violates our rules. Coverage changes would be caught by CI/CD and test processes. This is not suggesting any specific code changes. The dramatic drop in coverage could indicate a serious testing issue that needs attention. Maybe we should keep comments about such significant metrics changes? While the coverage drop is concerning, commenting on automated badge updates violates our rules. This should be handled by CI/CD processes and team metrics monitoring, not PR comments. Delete this comment. It's asking for verification of an automated process and doesn't suggest any specific code changes.

Workflow ID: wflow_kBa0YRUJ7WciydmX

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[dev-jodee]

Will work on it in another pr