Skip to content

Windows installer: stale roadmap numbering + missing Start-Process output redirects in install-k8s.ps1 #500

Description

@LukasWodka

Two Bugbot findings on the develop -> staging promotion (client#499), both Medium, both in scripts/install-k8s.ps1 and both from the recent Docker-Desktop/elevation work (#487 / #489). Neither blocks the promotion, but both are customer-visible on the Windows path, so they want closing before that installer reaches customers (part of the Windows installer epic, backend#1285).

1. Print-Roadmap still lists five steps (L~599)

The change added an Installing system tools phase, but the up-front Steps banner was not updated. So an operator sees Step 2/6 downloading ~700 MB while the roadmap printed at the start still says step 2 is cluster setup, and every later step is misnumbered.

That specifically undercuts the honest-progress split the change was making — the whole point of the phase separation was that a long download shouldn't look like a hang. Fix: regenerate the roadmap from the same step list the runtime uses, so the two cannot drift again.

2. New Start-Process installs have no output redirects (L~934)

The new tracked installs — Docker Desktop via winget, Docker Desktop via the direct installer, and winget k3d/helm — omit -RedirectStandardOutput / -RedirectStandardError to temp files. On failure the install log and the -Diagnose bundle get only a generic exit code, with no winget or installer output to explain it.

The same PR already does this correctly for the WSL and k3d cluster start paths, so this is an inconsistency inside one change rather than a missing convention. Given Windows installs are the ones we most often debug remotely from a customer's log (the [redacted]/UZ Gent and Anuba cases), losing installer stderr is expensive: it turns a one-look diagnosis into a round trip.

Fix: redirect both streams to temp files and fold them into the log / -Diagnose bundle on failure, matching the existing paths.

Refs

  • Bugbot on client#499 (develop -> staging promotion)
  • Related: backend#1285 (Windows installer epic), client#496 (the cgroup-delegation honesty finding from the same review round)

@saadqbal these are in your installer work — flagging rather than assigning, since you'll know whether they fold into an existing branch.

Metadata

Metadata

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions