Duckboot/cv4pve-cli-tui
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Live usage: CPU % and Mem % in the table, in-use on the info screen #24

Merged
Duckboot merged 1 commits from feat/live-usage-12 into main 2026-11-03 00:14:43 +01:00
Conversation 0 Commits 1 Files Changed 6
+356 -12
Duckboot commented 2026-11-02 23:52:44 +01:00
Owner
Copy link
Copy source

What

  • Guest table: two last columns, "CPU %" (cpu * 100) and "Mem %" (mem / maxmem), each with one decimal. They show - for a guest that is not running or lacks the field.

  • Info screen, Resources: the table gets a header and an "In use" column:

    • CPU %
    • memory in MiB, with %
    • swap, for containers
    • rootfs used in GiB, with %, for containers

    VM disks show -, because the API reports 0 without guest-agent disk info.

  • One status call: the info screen reads status and usage with a single status/current call (new cli.current).

  • After an action: the acted guest's status and usage both come from status/current. A guest that has just started no longer shows the lagging listing's 0.0 %.

Values refresh with the listing (g, or after an action). There is no auto-refresh and no rrddata trend.

Notes

  • One blind-written test expected a VM's CPU cell to read "4 cores". VMs have always shown sockets ("4 cores × 1 socket"), as the resources spec and its tests define, so that one expectation was corrected.
  • This PR is stacked on #22 (CI). Merge that one first.

Verification

  • 393 tests pass.
  • ruff check and ruff format --check report no issues.
  • betterleaks found no secrets.
  • Read-only live check:
    • CT 104: table 0.0 % / 6.8 %; info shows 35 MiB (7 %) memory, rootfs 0.7 GiB (39 %).
    • VM 108: table 0.5 % / 10.8 %; disk -.

Closes #12

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

## What - **Guest table:** two last columns, "CPU %" (`cpu * 100`) and "Mem %" (`mem / maxmem`), each with one decimal. They show `-` for a guest that is not running or lacks the field. - **Info screen, Resources:** the table gets a header and an "In use" column: - CPU % - memory in MiB, with % - swap, for containers - rootfs used in GiB, with %, for containers VM disks show `-`, because the API reports 0 without guest-agent disk info. - **One status call:** the info screen reads status and usage with a single `status/current` call (new `cli.current`). - **After an action:** the acted guest's status and usage both come from `status/current`. A guest that has just started no longer shows the lagging listing's 0.0 %. Values refresh with the listing (`g`, or after an action). There is no auto-refresh and no rrddata trend. ## Notes - One blind-written test expected a VM's CPU cell to read "4 cores". VMs have always shown sockets ("4 cores × 1 socket"), as the resources spec and its tests define, so that one expectation was corrected. - This PR is stacked on #22 (CI). Merge that one first. ## Verification - 393 tests pass. - `ruff check` and `ruff format --check` report no issues. - `betterleaks` found no secrets. - Read-only live check: - CT 104: table 0.0 % / 6.8 %; info shows 35 MiB (7 %) memory, rootfs 0.7 GiB (39 %). - VM 108: table 0.5 % / 10.8 %; disk `-`. Closes #12 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Duckboot added 2 commits 2026-11-02 23:52:44 +01:00
Add CI on Gitea Actions: pytest and ruff on every PR
CI / pytest and ruff (pull_request) Successful in 3m53s
Details
CI / pytest and ruff (push) Has been cancelled
Details
8c2b48a04c 
.gitea/workflows/ci.yaml runs on PRs into main and on pushes to main.
It installs uv, runs `uv sync --locked` with Python 3.12 (the lowest
version requires-python allows), then pytest, `ruff check` and
`ruff format --check`.

ruff is pinned in the dev group (0.17.3). The repo has no ruff config,
so the rules are ruff's defaults for that version; pinning makes CI
and local runs check the same rules. The setup follows the workflow
that already runs green on this Gitea instance (ubuntu-latest, pinned
checkout SHA, uv via the official script). The README gets a CI badge
and the lint commands.

Closes #11

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Show live usage: CPU % and Mem % in the table, in-use on the info screen
CI / pytest and ruff (pull_request) Successful in 3m49s
Details
CI / pytest and ruff (push) Has been cancelled
Details
eec65e0585 
The guest table gets two last columns, CPU % (cpu * 100) and Mem %
(mem / maxmem), each with one decimal. They show "-" for a guest that
is not running or lacks the field.

The info screen's Resources table gets a header and an "In use"
column: CPU %, memory MiB with %, swap for containers, and rootfs used
GiB with % for containers. VM disks show "-", because the API reports
0 without guest-agent disk info. The info screen reads status and
usage in one status/current call (new cli.current).

After an action, the acted guest's status and usage both come from
status/current, so a guest that has just started no longer shows the
lagging listing's 0.0 %.

One blind-written test expected a VM's CPU cell to read "4 cores". VMs
have always shown sockets ("4 cores × 1 socket", as the resources
spec and its tests define), so that expectation was corrected.

Closes #12

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Duckboot merged commit eec65e0585 into main 2026-11-03 00:14:43 +01:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
priority
1-high
Do first: biggest safety or maintenance gain
priority
2-medium
Next: clear everyday value
priority
3-low
Useful, but less often needed
priority
4-nice-to-have
Small conveniences; do when convenient
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
Duckboot (Per-Arne Hellarvik)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Duckboot/cv4pve-cli-tui#24