Skip to content

release(v0.0.23): fduty startup gate non-fatal + install.sh binary-only staging (#71)#72

Merged
ysyneu merged 1 commit into
mainfrom
feat/ai-sre
Jun 15, 2026
Merged

release(v0.0.23): fduty startup gate non-fatal + install.sh binary-only staging (#71)#72
ysyneu merged 1 commit into
mainfrom
feat/ai-sre

Conversation

@ysyneu

@ysyneu ysyneu commented Jun 15, 2026

Copy link
Copy Markdown
Collaborator

Releases #71 to main for the v0.0.23 cut.

  • non-fatal fduty startup gate (runner boots even when fduty is absent; logs an actionable hint)
  • install.sh stages bundled fduty on binary-only/darwin installs; mode-aware fduty_present short-circuit self-heals

All gates green on #71 (build/vet/test/gofumpt/shellcheck + live boot-through verification).

…on binary-only installs (#71)

Two coupled defects made a runner refuse to start when the `fduty` CLI was
absent — most visibly on macOS, where it failed immediately with
"fduty CLI not ready" after install.sh reported "Already at vX, nothing to do".

1. Startup gate was fatal. `ensureFdutyCLI` returned an error that aborted
   run/serve when fduty couldn't be provisioned or verified. A runner can still
   do non-fduty work, and a missing CLI is far easier to fix on a running,
   loudly-logging runner than on one that won't boot. It is now best-effort:
   it still auto-stages and self-checks fduty, but on failure it logs an
   actionable manual-install hint and the runner starts anyway. fduty calls
   127 until the operator resolves it — surfaced, not silently fatal.

2. install.sh never staged the bundled fduty on binary-only / darwin installs.
   `install_bundled_fduty` sat after the early `return` taken on the
   darwin/--no-service path, so the fduty shipped inside the release archive
   was extracted but never placed. Renamed to `stage_bundled_fduty(dir)` and
   now called on both paths: service installs stage into $BIN_DIR (the
   env-pinned runtime tools dir), binary-only/darwin into $INSTALL_DIR (on the
   user's PATH, and the dir darwin's bundledFdutyNextToExe() probes since
   os.Executable() there returns the /usr/local/bin symlink, not its target).
   The "already up to date" short-circuit now also requires `fduty_present`
   (mode-aware) so a re-run self-heals a missing fduty instead of declaring
   success while the CLI is absent.

Verified: runner boots through to the WS-connect stage with fduty fully absent
(no abort); install.sh staging + short-circuit logic unit-tested; go
build/vet/test, gofumpt, shellcheck all green.
@ysyneu ysyneu merged commit 2edd28f into main Jun 15, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant