Tags: RXTX4816/cockpit-compose
Tags
build(deps-dev): bump @testing-library/jest-dom from 7.0.0 to 7.0.1 (#… …299) Bumps [@testing-library/jest-dom](https://github.com/testing-library/jest-dom) from 7.0.0 to 7.0.1. - [Release notes](https://github.com/testing-library/jest-dom/releases) - [Changelog](https://github.com/testing-library/jest-dom/blob/main/CHANGELOG.md) - [Commits](testing-library/jest-dom@v7.0.0...v7.0.1) --- updated-dependencies: - dependency-name: "@testing-library/jest-dom" dependency-version: 7.0.1 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
build(deps-dev): bump @patternfly/react-core from 6.6.0 to 6.6.1 (#293) Bumps [@patternfly/react-core](https://github.com/patternfly/patternfly-react) from 6.6.0 to 6.6.1. - [Release notes](https://github.com/patternfly/patternfly-react/releases) - [Commits](https://github.com/patternfly/patternfly-react/compare/@patternfly/react-core@6.6.0...@patternfly/react-core@6.6.1) --- updated-dependencies: - dependency-name: "@patternfly/react-core" dependency-version: 6.6.1 dependency-type: direct:development update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
feat: poll the container engine's REST API to cut high idle CPU usage (… …#289) (#290) Addresses high CPU usage on slow/low-power hardware reported in #289, where cockpit-compose's background polling was found to dominate idle CPU cost. The main change: listContainers()/listStacks() now try the container engine's REST API directly over its Unix socket first (reusing the existing rootless/rootful socket detection), falling back to the exact prior CLI behavior on any failure. Process-spawn overhead dominates the cost of each poll, so this cuts the per-call cost roughly 10x rather than just changing how often calls happen. Scoped to pure reads only — every write path (up/down/pull/exec/logs/events/etc.) is untouched. Alongside that, a few compounding issues found during the investigation: - useComposeStacks had no guard against a new fetch starting while a prior one (from an earlier poll tick) was still in flight — since refresh() itself returns instantly, this let subprocess spawns pile up exactly like the un-paced polling described in the issue. It now skips a redundant fetch but coalesces exactly one follow-up run, so a user-triggered refresh (e.g. after finishing a stack action) is never silently dropped while busy. - useContainerStats was still polling via a raw setInterval with no overlap protection at all; migrated it to useAutoRefresh (see the companion base-react fix) for the same self-pacing/backoff behavior as everything else. - The compose file backing each stack was re-read (and re-spawned) on every poll just to recompute service names, even though it essentially never changes while the page is open. Now cached for 30s. - The top-level stack list poll interval was tightened from 500ms/2000ms to 1500ms/6000ms (idle/error), since a poll that frequent is disproportionately costly on constrained hardware relative to how often stack state actually changes on its own. - Stack and service actions (start/stop/restart/pause/unpause) only ever refreshed their own row's local container list, never the page-level stack summary — invisible while that poll ran every 500ms, but left completed actions looking stuck once the interval above was slowed down. All four row layouts now trigger an immediate page-level refresh on action success. Requires @rxtx4816/cockpit-plugin-base-react >=1.1.3 for the useAutoRefresh self-pacing/backoff fix these changes depend on.
fix: discover and manage rootful Podman stacks correctly (#242) (#245) Rootful Podman stacks (started via `sudo podman compose up`, no rootless socket available) were invisible in the dashboard because discovery ran unprivileged with no way to reach the root-owned socket. Escalate via Cockpit's superuser bridge whenever the active socket is rootful, and add a manual Rootless/Rootful toggle for when both sockets are available so detection failures no longer have to be silent. Also fixes several follow-on bugs found while chasing this down: - Podman compose delegating to a real Docker Compose plugin (when both engines are installed) could silently fall back to the wrong engine when no socket was confirmed. Now points at a deliberately unreachable socket in that case, so it fails loudly instead of succeeding against the wrong engine. - Compose-file ownership was overriding an explicit Rootless selection for Podman, letting a "down" issued in Rootless mode escalate to root and hit the Rootful stack instead. - src/api/containers.ts (service/container list, Stack Info modal) and the "Run in Background" flow's own duplicate escalation logic had no superuser escalation at all, so they always showed rootless-only data regardless of which mode was actually selected. - src/api/stacks.ts, an orphaned pre-refactor duplicate of the src/api/stacks/ directory, was silently shadowing it via esbuild's file-over-directory module resolution — every fix above had gone into code that was never actually bundled until this file was deleted and its two still-needed functions (image listing/pruning, run-with- entrypoint-override) were migrated to their real homes. Adds a rootful-only VM scenario (fedora-podman-rootful) and a combined scenario (fedora-full) for regression testing, an e2e admin-access helper (the shared pluginPage fixture never sees Cockpit's outer shell, so it can't reach the Administrative access control), and a regression test covering both the discovery fix and the Stack Info container list fix.
test(e2e): add shared helpers, wave 1 coverage, and adversarial tests (… …#227) (#239) Builds the shared e2e/helpers/ page-object layer (baseData, stack actions, runtime/rootless assertions, ensureDown self-healing against leaked state) and uses it to implement logs, exec, scale, prune, and create-stack coverage, plus a set of adversarial tests (malformed YAML, nonexistent scan directory, scan-depth bounds) that check the app fails safely rather than just rendering. Every test asserts a real backend effect (file content, container/volume state) rather than only DOM visibility, per the discussion in #227. Also documents the full suite in docs/wiki/E2E-Test-Reference.md (linked from the README and wiki sidebar) and the remaining backlog in docs/wiki/E2E-Test-Inventory.md, and corrects VM-Testing.md's resource guidance based on live-VM findings: the default VM_MEM=1024 is too tight for Postgres/exec-heavy specs, confirmed via in-guest swap usage. Surfaced two product questions worth follow-up: volume pruning appears unreachable through the current UI (a stack's Prune action disappears once its container count hits zero, which is exactly when Docker considers a volume "dangling"), and rootless Podman resets DownedStacksSection's local UI state for a few seconds after a runtime switch.
docs: fix stale wiki content and document features missing since past… … releases (#224) Bulk-Actions.md still described Minimal/Pretty layouts as using a checkbox for selection; #210 replaced that with click-to-select-glow a few releases ago and the wiki was never updated. Also documents the select-all toggle added in #216 (grays out the bar instead of hiding it when the selection empties). Background-Tasks.md claimed finished tasks can't reopen their log — no longer true after #217. Prune-Resources.md and Importing-Stacks.md had no mention of the new global "Prune images" action (#218) or the downed-stacks select-all and bulk Up feature (#220); Importing-Stacks.md was also missing the Restore and per-row Backup buttons, which predate this session but were never documented.
PreviousNext