wharfy 0.21.0 — verify stops skipping channels

verify now covers every channel

verify only looked at homebrew, releases, script, apt, rpm and goinstall. Everything else was skipped — and a skipped channel does not affect the outcome, so one passing channel made the whole run green even when the cask was never written to the tap, or the image had disappeared from the registry. You found out when a user could not install.

Installing from those channels needs macOS, Windows, Docker or Arch. But what is being served is readable over plain HTTP, and that is what verify reads.

Before

$ wharfy verify --version 1.2.0
✗ nothing to verify: skipped cask, container, winget
  ! nothing_to_verify: no channel in wharfy.yaml could be verified
    publish a channel that verify covers, or check why every channel was skipped

After

$ wharfy verify --version 1.2.0
✗ failed cask, container; partial winget
  ! verify_failed: the expected version is not on the tap
    re-publish to restore the cask
  ! verify_failed: the expected tag is not in the registry
    re-publish to push the image; `docker pull ghcr.io/acme/demo:1.2.0` is a 404 for users
  ⚠ gated_pending: winget 1.2.0 is not in microsoft/winget-pkgs yet …
next:
  wharfy publish cask --yes    # re-publish cask to fix what verify found
  wharfy publish container --yes # re-publish container to fix what verify found

Submitting is not shipping

On winget and homebrew-core, what reaches users is the manifest or formula that a Microsoft or Homebrew maintainer merges — so that is what verify reads. Until it is merged the channel is partial with a warning, never a failure: merging is the reviewer’s call, and waiting is the only move you have. If the upstream is stuck on an older version, verify says which version is being served, as in homebrew-core still carries 1.1.0, expected 1.2.0.

$ wharfy verify --version 1.2.0
✓ partial winget
  ⚠ gated_pending: winget 1.2.0 is not in microsoft/winget-pkgs yet: no manifests/a/acme/demo/1.2.0/acme.demo.yaml — `winget install acme.demo` still serves the previous version (the submission is merged by Microsoft, not by wharfy)

:latest is checked by digest

publish pushes the image under two tags, :<version> and :latest. If :latest is left on the old image, a user running docker pull <image> without a tag gets the old version. A tag is only a name, so verify compares the digests: a missing :latest, or a :latest pointing at a different image, both fail.

Fixed

• A GitHub release with no latest.json used to pass — the update check points at releases/latest/download/latest.json, which was a 404, while the asset check still passed. It is a failure now.
• A stale local record used to turn a perfectly fine distribution red — when publish runs in CI, the record only exists on the runner. verify now takes the version from what is actually published, the latest GitHub release, and only warns that the local record is behind.

Getting it

brew upgrade wharfy / scoop update wharfy / go install github.com/ShiroDoromoto/wharfy/cmd/wharfy@latest. On Linux, from the apt / yum repo.