OpsDeck/module_updates
Watch
2
0
Fork
You've already forked module_updates
 0
generated from OpsDeck/module_template
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

feat: show the pending update count on the nav entry #4

Manually merged
julian merged 0 commits from feat/nav-badge into main 2026-10-28 01:07:25 +01:00
Conversation 0 Commits - Files changed -
thisilike commented 2026-10-19 10:33:51 +02:00
Owner

The sidebar entry for Updates now shows a yellow pill with the number of pending packages. The hover text says how many of them are security updates.

Changes

  • load() calls ctx.ui.badge every time it produces a fresh state. That covers the collector tick, page views and the reload after a run.
  • If the simulation fails, the badge keeps its last value. This follows the module's existing rule for metrics: packages: [] from a host the module cannot read does not mean nothing is pending.
  • After a run, the state is reloaded in the background. The count drops when the upgrade finishes, instead of waiting up to 5 minutes for the next tick.

⚠️ Merge order

This needs OpsDeck/core feat/nav-badges, which adds ctx.ui.badge. On an older core the call throws and every page load fails. Deploy core first, then update the module's pinned sha.

This branch is based on main, separate from #3 (restart-host). The two don't overlap.

Verification

  • Inside a core checkout on feat/nav-badges: deno check backend/mod.ts is clean and deno test --allow-read backend/ passes (56 tests).
  • With a dummy badge forced at load, the sidebar showed a yellow, bold 29 in a browser. The real count is untested, because that needs a Debian host.

🤖 Generated with Claude Code

The sidebar entry for Updates now shows a yellow pill with the number of pending packages. The hover text says how many of them are security updates. ## Changes - `load()` calls `ctx.ui.badge` every time it produces a fresh state. That covers the collector tick, page views and the reload after a run. - If the simulation fails, the badge keeps its last value. This follows the module's existing rule for metrics: `packages: []` from a host the module cannot read does not mean nothing is pending. - After a run, the state is reloaded in the background. The count drops when the upgrade finishes, instead of waiting up to 5 minutes for the next tick. ## ⚠️ Merge order This needs OpsDeck/core `feat/nav-badges`, which adds `ctx.ui.badge`. On an older core the call throws and every page load fails. **Deploy core first**, then update the module's pinned sha. This branch is based on `main`, separate from #3 (restart-host). The two don't overlap. ## Verification - Inside a core checkout on `feat/nav-badges`: `deno check backend/mod.ts` is clean and `deno test --allow-read backend/` passes (56 tests). - With a dummy badge forced at load, the sidebar showed a yellow, bold **29** in a browser. The real count is untested, because that needs a Debian host. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Uses core's `ctx.ui.badge` (core feat/nav-badges): a warning-toned pill
with the number of pending packages, hover text naming how many are
security updates. Set wherever `load()` produces a fresh state, so the
collector tick, a page view and the post-run reload all keep it current.

A failed simulation leaves the badge alone rather than clearing it, for
the same reason it is never written as a metric: `packages: []` from an
unreadable host is not "nothing pending". After a run the state is
reloaded in the background instead of waiting up to five minutes for the
next tick, so the count drops when the upgrade finishes.

Needs a core that has `ctx.ui.badge`; on an older one the call throws
and every page load fails. Deploy core first.
On a core older than feat/nav-badges the call threw, and every page
load with it, so the merge order was load-bearing. Optional-call it.
Also say "1 update", not "1 updates".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
julian manually merged commit 68c369e1f8 into main 2026-10-28 01:07:25 +01:00
Sign in to join this conversation.
Reviewers
No reviewers
julian
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
OpsDeck/module_updates!4
No description provided.