v0.4 — Architecture hardening

What's changed

This release contains no functional changes — behaviour is identical to v0.3. The focus is internal architecture: making the update path easier to test, reason about, and extend.

Update strategy cascade (#4, #5)

update_batch previously embedded three strategies (App Manager → Scripted REST → background script fallback) in a single function, returning a polymorphic dict whose keys varied depending on which path succeeded. Callers had to inspect the method field to know what they received.

The strategies are now split into three named functions — _try_app_manager, _try_scripted_rest, _try_script_fallback — each owning its own logic and failure mode. update_batch is a five-line orchestrator.

Results are now typed via an UpdateResult dataclass with a fixed set of fields. Every path returns the same shape.

As part of this work, _parse_tracker (which normalises the many shapes a tracker ID can take across ServiceNow API responses) is now applied consistently to both API paths. Previously the plugin_overseer path did its own narrower inline extraction.

The dead _batch_payload function (payload was always built inline in the old update_batch) has been removed.

Application factory and testability seam (#6)

app.py is now structured as an application factory (create_app). Routes receive a ServiceNowClient via an injected factory rather than constructing one from environment variables inline. This means routes can be exercised without a live ServiceNow instance:

app = create_app(client_factory=lambda: FakeClient())

Environment variables (SN_INSTANCE, SN_USERNAME, SN_PASSWORD) are now validated at startup. A missing variable raises immediately rather than surfacing as a 500 on the first request.

v0.3 — Live Update Tracking

What's New

Live Progress Tracking

Updates now show real-time progress in the terminal and the progress banner. After triggering an update you'll see:

18:41:48  INFO  UPDATE  Now Assist for code generation queued via app_manager  (tracker: d6f6e8ca)
18:41:53  INFO  STATUS  [d6f6e8ca] running  25%  Installing packages...
18:42:08  INFO  STATUS  [d6f6e8ca] COMPLETE ✓  100%  Installed Successfully

App Manager & sn_cicd Integration

• Tracker IDs are now correctly extracted from the App Manager response (batchInfo.execution_tracker_id, trackerId, and links.progress.id)
• Status polling now uses the sn_cicd progress API (/api/sn_cicd/progress/{id}), which is what the App Manager uses internally — with fallback to sys_progress_worker for the custom endpoint
• Numeric sn_cicd status codes (0–4) are mapped to readable states (pending, running, complete, failed, cancelled)

Version-Polling Fallback

When no tracker ID is available, the dashboard now polls the plugin's installed version directly (via a new /api/snc/plugin_overseer/version/{sys_id} endpoint) and detects completion when version == latest_version. This ensures the row always reaches ✓ Done even without a tracker.

Timestamps

All terminal log lines now include a timestamp (HH:MM:SS) so you can tell exactly when updates start, progress, and complete.

Queued State

When an update is queued behind another install already in progress, the progress banner now shows "Waiting for other installs to complete…" rather than appearing frozen at 0%.

Bug Fixes

• Fixed tracker ID extraction — the App Manager response nests IDs under batchInfo and links.progress, which the parser now handles
• Fixed 404 errors on status polling caused by polling sys_progress_worker for sn_cicd tracker IDs
• "successful" added as a recognised terminal success state (sn_cicd uses this instead of "complete")

v0.2 — Update Tracking, Dependencies & Logging

What's New

Update Progress & Feedback

• Progress banner — a bar slides up from the bottom of the screen when a batch update is triggered, showing live % progress and status messages from ServiceNow
• Completion toast — green confirmation appears when an update finishes; red on failure
• Per-row status — individual plugin rows now show live state (Queued…, 42%, ✓ Done, ✕ Failed) during and after updates
• Queued state — when ServiceNow is busy with another install, the banner now shows "Waiting for other installs to complete…" instead of appearing frozen

Update Reliability

• Three-tier fallback chain — update attempts now try in order:
  1. Native App Manager API (/api/sn_appclient/v1/appmanager/product/install)
  2. Custom Plugin Overseer Scripted REST API
  3. Generated background script (manual fallback via modal)
• Batch tracking fixed — selecting multiple plugins and clicking Update Selected now correctly tracks all chosen plugins and marks each row done on completion
• Script fallback modal improved — includes numbered steps and a direct link to the ServiceNow background scripts page on your instance

Plugin Dependencies

• Requires section — expanding a plugin row now shows which other plugins it depends on
• Dependency warning — if a required plugin also has an update available, its chip turns amber with a ⚠ indicator
• Dependency badge — plugins that were auto-installed as a dependency of another plugin are labelled in the status column

Logging

• Werkzeug's raw HTTP access log suppressed; replaced with descriptive per-action log lines
• Update log clearly distinguishes between queued via API and fallback to background script
• Status polling only logs on meaningful state changes (progress or terminal state), not every poll tick
• Completion logged once with COMPLETE ✓ or warning for errors

Bug Fixes

• Batch and Update All buttons now poll the tracker and update rows — previously fire-and-forget with no feedback
• Script fallback warning (WARNING) no longer logged as ERROR

v0.1

Initial beta release for ServiceNow Plugin Overseer