Files
at-container-registry/pkg/appview/templates
Evan JarrettandClaude Opus 5 f16a8eaa82 appview: warn about a deprecated chart on the tab people actually land on
8487258 added the deprecation notice to the shared helm metadata partial, on
the understanding that both the Overview and Chart tabs rendered it. Only the
Chart tab does. The Overview panel renders the README and never touches chart
metadata, so a deprecated chart carried no warning on the default landing tab.

The notice is extracted into a shared helm-deprecation-notice block, so the
copy lives in one place, and the Overview panel renders it server-side as the
first element in the panel. Deprecation decides whether you should use the
chart at all, so it belongs in the first paint rather than arriving a beat
later from a lazy fetch.

Getting the data there costs nothing extra. The page already made a blocking
hold call for layer count, and for a chart that call was wasted: a helm config
blob is Chart.yaml, which has no history key, so the count always came back 0
and fell through to the database. That call is now FetchHelmChartMeta instead,
against the same XRPC endpoint, so a chart page makes one hold call rather than
two and the displayed layer count is unchanged. A container image never fetches
chart metadata and its path is byte-for-byte the old code.

Failure follows the layer-count precedent: log at warn, leave the metadata nil,
render the page. An unreachable hold means no notice, not a broken repository
page. The tradeoff against the lazy version is that a slow-but-up hold now
delays the whole page, bounded by the same 10s the page already accepted.

A container image emits no element at all rather than an empty one, so the
space-y-4 stack spacing is untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PDqoCE1j3njokkZ9b1C5n9
2026-09-02 22:37:18 -05:00
..