Coverage baseline

[insatomcat]

Establishes a measured coverage baseline for vm_manager, as a first step
towards the OpenSSF Best Practices gold criteria test_statement_coverage90
and test_branch_coverage80.

What it contains

• Unit tests for the vm_manager_cmd CLI (55 tests). They monkeypatch
  the public API, so they check argument parsing and dispatch, not the
  backends. vm_manager_cmd.py goes to 92%.
• Cluster-mode tests runnable without Ceph. tests/conftest.py installs
  the stubs from tests/ceph_stubs.py before importing vm_manager, because
  the backend is chosen at import time in __init__.py. Without them
  cluster_mode is False on any machine without Ceph and every cluster-side
  test is skipped, including those that need no cluster at all. The stubs
  raise on use, so a test that reaches real Ceph code fails loudly instead of
  passing quietly.
• Coverage measured and published in CI, in the run summary, so the
  figures are readable and linkable without any third party service.
• A CI hardening commit, detailed below.
• SonarCloud analysed from the workflow instead of Automatic Analysis,
  which is what finally lets the coverage report reach SonarCloud. Also
  detailed below.

The baseline

TOTAL   1529 statements   560 branches   26%
153 passed, 3 xfailed

26% is low and the reason is structural, not a gap in the suite. CI runs 87
of the 178 test functions. The 91 it ignores are test_vm_manager_cluster.py
and test_vm_manager_cmd_cluster.py, which need a real Ceph and Pacemaker
cluster. Those are exactly the tests covering vm_manager_cluster.py,
rbd_manager.py and pacemaker.py, which together are 1115 of the 1529
statements. Closing the gap means unit tests with the bindings and the crm
CLI mocked, which is the next step, not this one.

There is deliberately no fail_under yet. Setting a threshold before
having an honest baseline would only encode the current state as a target.

SonarCloud will show 21.2%, not 26%, and both are correct. The two
figures measure slightly different things, so it is worth writing the
reconciliation down once:

• pyproject.toml omits vm_manager/helpers/tests/* from the measurement,
  the hand-run integration scripts. That is 522 statements. 1529 + 522 =
  2051, against the 2042 coverable lines SonarCloud reports: same code, plus
  those scripts, counted as fully uncovered. They are shipped in the
  installed package, so SonarCloud is right to count them, and the scope is
  deliberately left alone rather than tuned to make the two numbers agree.
• pytest reports one blended figure over statements and branches. SonarCloud
  reports them apart: 22.4% line, 16.6% branch, 21.2% overall.

The CI hardening commit

It exists because SonarCloud reported four findings on the two pip install
lines, under two rules, and both are legitimate.

• githubactions:S8544, dependencies without locked versions. Fixed with
  requirements-ci.txt used as a pip constraints file. The permissive
  ranges in pyproject.toml are untouched, so nothing changes for anyone
  installing the package. Only CI is pinned.
• githubactions:S8541, source distributions may run setup scripts at
  install time. Fixed with --only-binary :all:, with libvirt-python
  excluded by name: it publishes no wheel on PyPI and compiles against the
  system libvirt headers, which is what the libvirt-dev and pkg-config
  apt packages in the workflow are for. Naming it keeps source builds to that
  single reviewed package rather than reopening them for the whole dependency
  graph.

The install is also editable. Coverage instruments the package in the
checkout, so the tests must import it from there. A regular install copies it
to site-packages, the tests import that copy, and coverage reports 0% on
every module while the suite passes.

SonarCloud analysed from the workflow

The project ran SonarCloud Automatic Analysis: the GitHub App analysed
every push server-side, with no scanner in the repository. That mode cannot
serve this change, for two reasons.

• It never runs the build or the tests, so it cannot import a coverage
  report. SonarCloud has had no coverage data at all for this project:
  the coverage metric is simply absent from the project measures, and
  new_lines_to_cover is 0 on pull requests. Producing a coverage.xml in
  CI is useless as long as nothing can consume it.
• It has no git history to blame lines with, so on a pull request every line
  of a touched file counts as new code. That is why this branch first went
  red on a line of ci.yml identical to main, at the same line number,
  dated 2026-02-19 by SonarCloud itself, while main stayed green on the
  same finding.

So the scanner now runs from the test job, after the tests, with
fetch-depth: 0 so blame works, and sonar-project.properties declares the
coverage report path. Scope stays the whole repository as it was under
Automatic Analysis, so the workflow, Dockerfile and XML analysers keep
reporting. The step is skipped when SONAR_TOKEN is absent, which is the
case for pull requests from forks: those keep the rest of the job.

Automatic Analysis has been turned off in the project settings and the
SONAR_TOKEN repository secret is in place, both prerequisites for the
above. The trade-off is worth stating: pull requests from forks are no
longer analysed at all, where Automatic Analysis did analyse them. In
exchange the project gets coverage and correct new-code detection, neither
of which Automatic Analysis can ever provide.

This already works on this pull request. The analysis run from the workflow
reports coverage 21.2, line_coverage 22.4, branch_coverage 16.6 over
2042 coverable lines, and the quality gate is green. Before it, the
coverage metric did not exist on the project at all.

Known issues left open on purpose

Three tests are marked xfail(strict=True) because they document two real
CLI bugs rather than hide them:

• create --disable and clone --disable disable nothing. main() only
  assigns args.enable under if "enable" in args, but enable is never an
  argparse dest for those subcommands, so the key never reaches the backend
  and _configure_vm() treats a missing enable as True.
• create --enable-live-migration is a no-op, same pattern with
  if "live_migration" in args.

add-to-cluster assigns both unconditionally and is the correct reference.
Fixing them changes CLI behaviour, so it belongs in its own change.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud