Add shortcut link in containers to their github projects.

[begunfx]

Add shortcut link in containers to their github projects. If possible, maybe even better if the link goes directly to the project changelog. Would be nice to quickly see the details of the changes to a container with the update available for visibility before deciding to execute the update.

[s-b-e-n-s-o-n]

This overlaps with an existing roadmap item — Phase 4.8 ("Release Notes in UI & Notifications") already plans to map container images to their source repositories (GHCR → GitHub repo via OCI metadata, Docker Hub source URL, etc.) and surface release notes inline in the container detail panel. A shortcut link to the repo — and a direct link to the changelog for supported hosts — falls out naturally once that mapping exists.

Tracked under v1.6.0's Notifications & Release Intel work. Coming.

[s-b-e-n-s-o-n]

Hey @begunfx — shipping in rc.10. Two pieces:

• "View project" link next to the container name (GitHub/GitLab/external icon based on host). Picks up the source URL from the OCI org.opencontainers.image.source label, a dd.source.repo override label, or GHCR metadata — in that order. No configuration needed when the image ships the standard label.
• "Release notes" expander that opens inline when GitHub Releases (or equivalent) has notes for the version available in newTag. Shows title + truncated body up to 200 chars, with a "View full notes" link to the exact release page — so you land on the v12.3.2 → v12.3.3 diff rather than the project's full CHANGELOG. Falls back to a plain external link when only a URL is available.

Both surface in the grouped list card and the container detail panels (side tab + full-page overview/tabs).

Curious what you think once rc.10 drops — does the per-release notes expander scratch the "see what changed before I update" itch you described, or would a link to the project's top-level CHANGELOG.md still be useful alongside it?

[begunfx]

Not seeing either one of the new additions. Either they are there but hard to find or missing. See attached screenshot:

[s-b-e-n-s-o-n]

You're right, and good catch — the rc.10 wire-up landed in the cards view and the detail panels, but I missed the list accordion view, which is what your screenshot is showing on the left.

You can actually see the feature working in the same screenshot: the detail panel on the right for prowlarr is already rendering View project (because the container exposes org.opencontainers.image.source via the linuxserver.io image labels). The list rows on the left just didn't have a slot for the links — they were hiding until you opened the row into the detail panel.

Fix

Added the same SuggestedTagBadge + ReleaseNotesLink + ProjectLink row that the cards view renders to the list view item, gated on the same condition (suggestedTag || releaseNotes || releaseLink || sourceRepo). Rows without that metadata keep their current layout. Regression test asserts both project-link and release-link render in list-mode when the container populates them, tagged (#295) so the wire-up can't quietly fall off again.

What you'll see on the next RC

• prowlarr, qbittorrent, radarr, netbox, calibre, tdarr_node (everything linuxserver.io/ghcr in your screenshot) — a small View project link per row, clicking through to the GitHub source repo. That drops out of the org.opencontainers.image.source label lscr.io sets.
• Release notes inline only when the upstream project publishes structured GitHub Releases for the exact version in newTag. Some of your LinuxServer images publish notes on the linuxserver/docker-* repo (those will show), and some only tag the app-version on the upstream project repo with no attached release notes — those will only surface the external link, not the expandable body. That's upstream-controlled, not a Drydock gap.

Still table-view

The table view's kind column is icon-density-constrained — stuffing text links in there without a dedicated column would crowd the row at narrow widths. The detail panel already has both links, so table-view users can still reach them with a single click. If you'd rather have an inline-in-the-row option in table view, I can add a dedicated "Links" column as a follow-up — just let me know.

Ships in the next RC. Thanks for the screenshot, the detail-panel-shows-it-but-list-doesn't gap was immediately obvious from it.

[s-b-e-n-s-o-n]

You're right — that's the compact table view that appears when the detail panel is open (or the viewport is narrow), not the list accordion. My first pass only covered the list view, so the squished rows in your screenshot still weren't getting the links. Thanks for catching it.

What shipped in this follow-up

• Compact table rows (your screenshot): icon-only Release notes and View project links now sit in the folded badge cluster inside the name cell — same row, right edge, 24×24 tap targets with tooltips. They appear only when the container exposes releaseNotes, releaseLink, or sourceRepo, so rows without that metadata stay uncluttered.
• Table "More" (⋯) menu: non-compact table users (wide viewport, detail panel closed) reach the same two links via the actions overflow menu, with text labels for readability. This keeps every table-view path consistent, finger-friendly, and screen-reader-labeled.
• List accordion (RC10 fix): still there, text links in the existing SuggestedTag/ReleaseNotes row.
• Cards + detail panel: unchanged — already had text links since RC10.

What you'll see on the next RC

• prowlarr, qbittorrent, radarr, netbox, calibre, tdarr_node, nginx (lscr) — a small View project icon in every row (in the compact view) or in the ⋯ menu (in the wide view), linking to the GitHub source repo via org.opencontainers.image.source.
• Release notes icon inline when the upstream publishes structured GitHub Releases for the exact version in newTag. Some linuxserver.io images publish on the linuxserver/docker-* repo (those will show), some only tag on the upstream repo with no attached notes (those fall back to just the external release link — still a tap target, just no inline body). That's upstream-controlled, not a Drydock gap.

On the bigger picture

The ⋯-menu + folded-row pattern ships the feature in every view, but it's an interim placement — a dedicated compact "Links" column in the table (mirroring the Kind column, icons only, touch-sized) would be the proper home. That's already queued under the v1.6.0 "Design polish" pass in the roadmap (mobile-friendly views + standardized per-row quick-action iconography across list/card/table), where we can make one consistent decision for every view at once rather than tweaking it surface-by-surface. Appreciate you pushing back on the initial fix — it shook out a cleaner outcome.

Ships in the next RC.

[s-b-e-n-s-o-n]

Small correction on my last reply — after another pass over the compact row, we moved the icons out of the cell-name badge cluster and the ⋯ overflow menu and landed them as icon-style actions in the actions column itself, so they sit next to the existing Update / Stop / Restart / More icons, share the same 44×44 tap target, and pick up the same muted/hover treatment as the other row actions.

Under the hood, AppIconButton now accepts an href and renders as a proper anchor when one is provided, and ProjectLink / ReleaseNotesLink compose it directly in their icon-only mode — so it's one shared action-icon component, not bespoke styling per link.

Net effect in the table on the next RC:

• Rows with org.opencontainers.image.source (prowlarr, qbittorrent, radarr, netbox, calibre, tdarr_node, nginx-lscr, etc.) get a project icon in the actions column that opens the upstream repo.
• Rows where the upstream publishes structured GitHub Releases for newTag get a release notes icon next to it. If the upstream just tags the version without attached notes, only the external release link icon shows.
• Rows without either stay visually unchanged.

Cards view and the slide-in detail panel still use the original text links. The list accordion view also has the text links. All three affordances line up to the same "v1.6.0 Design polish" UI pass in the roadmap, where we'll pick one standardized iconography across all four surfaces.

[begunfx]

I'm still not seeing any project changelogs for containers. Maybe I'm missing where they are supposed to live but don't see them in rc.14.

[s-b-e-n-s-o-n]

@begunfx — apologies for the runaround. Looking at this fresh in rc.14, you're correct: most of your containers have no changelog visible. Two real bugs in what shipped, plus a design gap I should have caught:

Design gap (the main one). Release notes only enriched when updateAvailable === true. Up-to-date containers — which is most of yours — got nothing, by design. That's the wrong default. You want to see what's in the version you're running regardless of whether there's an update pending; the "before I update" use case is a bonus on top.

Bug 1: legacy containers never picked up source labels. Source repo detection ran once at watcher time, then never again unless the image identity changed. Containers persisted before rc.10 stayed empty forever — including most of your linuxserver.io rows.

Bug 2: fallback re-resolution dropped image labels. When the watcher path didn't populate sourceRepo, the enricher's fallback re-resolve only inspected container labels, not image labels — so the standard org.opencontainers.image.source label that lscr.io and most OCI images set was effectively invisible to that path.

What's in rc.15:

• currentReleaseNotes always populates for the running tag when the upstream publishes structured releases — independent of whether an update is pending.
• When an update is pending and the new tag differs, both panels render stacked with version labels (Release notes — v1.5.0 Release (current) and Release notes — v1.5.1 Release (available)). Same version, one panel.
• Source-repo detection backfills every watch cycle when missing, so existing legacy containers self-heal on their next poll — no restart, no image change required.
• Image labels now flow through the fallback re-resolve path, so the OCI source label is read on every code path, not just first-detection.

Tested at 100% coverage across the watcher, enrichment, mapper, and component layers. Tagged (#295) end-to-end so this can't quietly regress.

You should see changelog panels on prowlarr, qbittorrent, radarr, calibre, and tdarr_node out of the box. Some lscr.io images publish releases on the linuxserver/docker-* repo, others only tag the upstream — that part is upstream-controlled, but at least the project link will always be there.

[s-b-e-n-s-o-n]

The bugs fixed in rc.15 (source-label backfill not running for legacy containers, image labels not flowing through the fallback enricher path) are both still in v1.5.0-rc.19 — the current release.

If you're on rc.19 and still not seeing project links or release notes on your linuxserver.io containers (prowlarr, qbittorrent, radarr, etc.), the most likely cause is that the containers predate rc.10 and haven't gone through a watch cycle yet on rc.15+. The backfill runs on the next watcher poll — either wait for the scheduled cron tick or restart Drydock once to trigger an immediate scan.

What to expect after that:

• "View project" link per row for lscr.io images (via org.opencontainers.image.source)
• Release notes expander inline when the upstream publishes structured GitHub Releases for your current or available version

The remaining work — standardizing the icon placement consistently across cards/list/table — is queued for the v1.6.0 Design polish pass. The feature is fully functional; that pass is about visual consistency, not new capability.

Can you confirm whether project links show up after a scan cycle on rc.19? Happy to mark this answered once confirmed.

Release: https://github.com/CodesWhat/drydock/releases/tag/v1.5.0-rc.19

[begunfx]

on rc.19. I can see the release notes link on the right but still do not see any expander in the container view. See screenshot below:

In the security view I can see the expander for the notes:

[s-b-e-n-s-o-n]

Hey @begunfx — the asymmetry is by design and clearly isn't obvious enough. The container table view uses an icon button + popover (the file-text icon in the actions column) to keep dense rows compact, while the security view uses an always-inline expander since its rows have less competing for space. Clicking the file-text icon opens a popover with the same expander you see inline in the security view — same content, same chevrons, same body preview, just gated behind a click in the table view.

If you'd prefer always-visible inline expanders, the Cards and List view modes (the toggle in the top-right of the Containers page) both render the expander directly in the row — switching to either gives you the same UX as the security view.

If clicking the icon does nothing on rc.19, that's a different bug and I'd want to dig in — let me know.

[begunfx]

@s-b-e-n-s-o-n I'm not seeing the icon button + popover in the actions column. I'm only seeing the shortcut to the notes.

[s-b-e-n-s-o-n]

🚀 Shipped in v1.5.0-rc.21 — the file-text icon in the container table now opens the same popover whether the container has structured release notes or just an external releaseLink. Single consistent affordance across both cases.

[begunfx]

This works a lot better

Thanks!