feat(ci): include e2e tests in coverage measurement

[lh-sag]

Summary

Measure coverage across the whole suite (Rust unit/integration/doc + Python e2e) as one merged report.

Local: 213 tests pass, ~87% line coverage.

Checklist

• I have tested my changes locally
• I have added or updated documentation
• I have linked related issues or discussions
• I have added or updated tests

[Copilot]

Pull request overview

Unifies coverage collection so the cargo-llvm-cov report includes Rust unit/integration/doc tests plus Python (and Bruno) e2e tests as a single merged report, exposed via PR comment, GitHub Step Summary, and Pages artifact.

Changes:

• Add a --opensovd-coverage pytest option that sets up cargo llvm-cov instrumentation via show-env in pytest_configure and renders JSON/HTML/Cobertura in pytest_sessionfinish.
• Update the CI coverage job to drive coverage via uv run pytest, install Node/Bruno/uv, and post or update a sticky PR coverage comment.
• Add scripts/coverage-report.sh to render a Markdown coverage summary/detail from the JSON report, and use --locked --all-features for cargo invocations in tests.

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
.github/workflows/ci.yaml	Switches coverage to pytest, installs e2e tooling, posts sticky PR coverage comment.
tests/conftest.py	Adds --opensovd-coverage, sets up llvm-cov env, writes merged report at session end.
tests/test_rust.py	Adds --locked --all-features to cargo test list/doc-test invocations.
tests/fixtures.py	Adds --locked to gateway cargo build.
scripts/coverage-report.sh	New Markdown renderer for the cargo-llvm-cov JSON report (summary/detail).
.gitignore	Ignores generated coverage.json.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Coverage: 87.48%

3242 of 3706 lines covered (Rust unit tests + e2e).

Crate	Lines	Coverage
opensovd-cli	713/820	86.95%
opensovd-client	319/341	93.54%
opensovd-core	401/514	78.01%
opensovd-extra	144/158	91.13%
opensovd-mocks	146/146	100%
opensovd-models	79/79	100%
opensovd-providers	137/220	62.27%
opensovd-server	1303/1428	91.24%

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated no new comments.

[alexmohr]

@lh-sg We're building something really similar in cicd-workflows repo. and in CDA eclipse-opensovd/classic-diagnostic-adapter#360

@theswiftfox is also working on integrating cargo crap (eclipse-opensovd/classic-diagnostic-adapter#346)

1. Are we able to find a common ground for coverage reporting? Would also help us once we want to make releases for s-core where we have to provide the test results in a shared format.
2. Are you intereseted in cargo crap as well? We could provide it as a shared workflow once we collected some experience in the CDA with it? But I don't see the point of nagging about sharing infrastructure when no one actually cares :)

[lh-sag]

@lh-sg We're building something really similar in cicd-workflows repo. and in CDA eclipse-opensovd/classic-diagnostic-adapter#360

The primary goal of this PR is to include e2e tests in code coverage as it increased coverage results significantly.

The pr comment was just to verify that it works before I actually merge something. I can use whatever is available. But it seems coverage was just added recently, it was not there when I checked last time.
Should we maybe sync before making decisions or actions? I would also be happy to re-use more or at least have a similar concept to SCORE.

@theswiftfox is also working on integrating cargo crap (eclipse-opensovd/classic-diagnostic-adapter#346)

1. Are we able to find a common ground for coverage reporting? Would also help us once we want to make releases for s-core where we have to provide the test results in a shared format.

Sure. As I said. Last time I checked there was no coverage at all.

2. Are you intereseted in cargo crap as well? We could provide it as a shared workflow once we collected some experience in the CDA with it? But I don't see the point of nagging about sharing infrastructure when no one actually cares :)

I dont know crap or it its intention. Need to take a look. Lets talk.

[theswiftfox]

@lh-sag
For cargo-crap there is a neat blogpost of the author: https://minikin.me/blog/cargo-crap
Its a fun read :)

Note: I had to fork it and fix some things related to matching between the scores and the coverage data for bigger projects with a single workspace. I want to create a PR in the upstream repo for that though.

[lh-sag]

@lh-sag For cargo-crap there is a neat blogpost of the author: https://minikin.me/blog/cargo-crap Its a fun read :)

Note: I had to fork it and fix some things related to matching between the scores and the coverage data for bigger projects with a single workspace. I want to create a PR in the upstream repo for that though.

Will take a look thanks for sharing @theswiftfox . What is your personal verdict about the tool?

[theswiftfox]

@lh-sag For cargo-crap there is a neat blogpost of the author: https://minikin.me/blog/cargo-crap Its a fun read :)
Note: I had to fork it and fix some things related to matching between the scores and the coverage data for bigger projects with a single workspace. I want to create a PR in the upstream repo for that though.

Will take a look thanks for sharing @theswiftfox . What is your personal verdict about the tool?

I was positively surprised by the output from the get go. While it has some false positives (like flagging this const fn with a high score, due to the massive match block), most of the time the functions that were scoring high are in fact the things we are aware of needing a refractor.
As it matches the score it generates against the coverage of the method, the output is a good indicator for code that can be risky when changed.

tl/dr:
you can't follow it blindly, but if it flags a regression in a PR its a good indicator to take a second look at the function and decide if its worth either making the function more readable / less complex or if additional tests are the way to go. And I am very fond of any tool that can assist in identifying the most critical places for a review.

[lh-sag]

2. Are you interested in the Cargo stuff as well? We could offer it as a shared workflow once we've gathered some experience with it in the CDA. That said, I don't see much point in pushing shared infrastructure when no one actually cares about it :)

The recent CI changes are all agentic, so we could easily fire off a few agents to handle this.
What's holding me back from contributing, despite being the one who triggered the shared CI/CD repo in the first place, is that we don't share a common understanding of how it should look in the bigger picture.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated no new comments.