Documentation
¶
Index ¶
- Constants
- func Config(version string) selfupdate.Config
- func ConfigFor(id, version string) selfupdate.Config
- type ChildRequest
- type ChildResult
- type Output
- type Service
- func (service Service) AfterUpdate(ctx context.Context, update selfupdate.AfterUpdate, output Output) error
- func (service Service) RestartDaemon(output Output, parent context.Context, update selfupdate.AfterUpdate)
- func (service Service) SyncSkills(output Output, parent context.Context, update selfupdate.AfterUpdate) error
Constants ¶
const CatalogID = "wb"
CatalogID is wb's own id in github.com/strongo/cli-helpers/cliinstall's compiled-in fleet catalog (cli-install#req:host-identity-from-catalog). newSelfUpdateConfig and newInstallCmd both resolve this SAME entry, so `wb self-update` and every other fleet CLI's `install wb` agree on how wb is released, by construction rather than by two copies staying in sync (cli-install#req:catalog-identity-single-source).
const HandoffMargin = 5 * time.Second
const HomebrewInstallCommand = "brew install --cask sneat-dev/tap/wb"
HomebrewInstallCommand is named alongside elevated permissions in the permission-failure remedy. It only ever fires on the manual-install path — a Homebrew-managed install is redirected long before any write is attempted — so a user who hit a permission error is pointed at wb's supported install channel instead of being left with only "run as sudo" (REQ: permission-remedy-names-brew).
const HomebrewUpgradeCommand = "brew update && brew upgrade --yes --cask -- wb"
HomebrewUpgradeCommand is the exact command printed for a Homebrew-managed install. wb ships as a cask, not a formula, so this must carry --cask (REQ: wb-homebrew-cask).
Variables ¶
This section is empty.
Functions ¶
func Config ¶
func Config(version string) selfupdate.Config
newSelfUpdateConfig returns wb's own selfupdate.Config, built from its compiled-in cliinstall catalog entry rather than restated by hand (cli-install#req:catalog-identity-single-source; REQ: wb-release-identity, REQ: wb-homebrew-cask, REQ: wb-version-identity). It is a plain function, not inlined into newSelfUpdateCmd, purely so selfupdate_test.go can assert its fields directly without constructing a command or touching any I/O.
The catalog entry (github.com/strongo/cli-helpers/cliinstall's own catalog_wb.go) already reproduces wb's release identity field for field — the GitHub repository, the Homebrew cask manager (selfupdate.HomebrewCask("wb"), whose UpgradeCommand is byte-identical to HomebrewUpgradeCommand below), the supported darwin/linux platforms .goreleaser.yml publishes, the {"version","--json"} probe args, and the "unknown"/"(devel)" undetermined placeholders — so binding it here is not a behavior change, only a single source of truth: a future drift between wb's own self-update and any other fleet CLI's `install wb` now fails cli-helpers' own catalog-snapshot tests instead of silently diverging between two hand-copied literals.
func ConfigFor ¶
func ConfigFor(id, version string) selfupdate.Config
Types ¶
type ChildRequest ¶
type ChildResult ¶
type ChildResult struct{ Combined, Stdout, Stderr []byte }
func RunChild ¶
func RunChild(ctx context.Context, request ChildRequest) (ChildResult, error)
RunChild executes the verified provider identity with the requested capture mode.
type Service ¶
type Service struct {
RunChild func(context.Context, ChildRequest) (ChildResult, error)
HandoffTimeout func() time.Duration
}
func (Service) AfterUpdate ¶
func (service Service) AfterUpdate(ctx context.Context, update selfupdate.AfterUpdate, output Output) error
func (Service) RestartDaemon ¶
func (service Service) RestartDaemon(output Output, parent context.Context, update selfupdate.AfterUpdate)
func (Service) SyncSkills ¶
func (service Service) SyncSkills(output Output, parent context.Context, update selfupdate.AfterUpdate) error
syncSkillsAfterSelfUpdate runs `skills sync` against the exact installed executable identity resolved by the shared self-update provider.
It re-execs the installed binary rather than calling the shared skillsync adapter in this process: when self-update actually swapped the executable, this process is still running the OLD build in memory (replacing the file on disk does not reload an already-running process), so only a fresh child process sees the newly embedded skills. It resolves the configured binary name on PATH first: Homebrew's stable launcher survives a cask upgrade, whereas os.Executable can still name the deleted old Caskroom target.
A failure here is never fatal to self-update: the update itself already succeeded (or there was nothing to do), so a sync that cannot run -- offline, a permissions issue, no harness present yet -- is reported as a warning on stderr rather than turned into a self-update failure.
Source Files