feat(applications): surface per-app release-notes link in the applications view (BUNYIP-343) #368

Merged

longjacksonle merged 1 commit from feat/BUNYIP-343-application-release-notes into main

2026-07-13 22:09:04 +02:00

longjacksonle commented

2026-07-13 21:57:46 +02:00

Owner

What

Surfaces a per-application "Release notes" link in the applications view (BUNYIP-343). Adds an admin-editable release_notes_url column, modelled exactly on the existing source_code_url field, and renders it on each application card.

Blocker resolution

The 2026-07-10 audit flagged three gaps; resolved here:

The app -> URL map is now a real column, seeded for the known hosted apps (Mokosh, Drillmark) with their public Forgejo releases page and editable from the admin UI - explicit and correctable, not guessed.
Wrong path anchor: the view is bunyip-web's Maud app_card fed by bunyip-api, not src/pages/applications.
Where the association lives: on the applications row.

Changes

Migration adds the nullable release_notes_url column and seeds mokosh / drillmark (guarded on IS NULL so an admin edit is never clobbered).
Column threaded through Application, ApplicationResponse, CreateApplication/UpdateApplication, and the repository create/update SQL (appended as the highest bind parameter so existing positional params are untouched; runtime queries, no .sqlx regen).
Admin form: a "Release notes URL" field via the shared DetailsView, so create and edit stay in sync. The admin API already accepts it (both handlers deserialize into Create/UpdateApplication).
app_card renders a "Release notes" link (new tab) when set, omitting it otherwise.

Why a stored column, not derived from Forgejo config

The hosted launch tiles carry no Forgejo repo config; the download products point at the private psa-systems-private org (release pages not public); and one app can map to multiple repos. A derived URL would surface on ~zero real apps and could not express the mapping. The column decouples release-notes from download config and lets ops fix links without a deploy. (Chosen with the reporter.)

Verification

Against a real Postgres: all migrations apply, the release_notes_url column exists, and the seed lands (mokosh -> .../mokosh-server/releases, drillmark -> .../drillmark/releases).
Unit tests cover the response carrying the column and app_card rendering/omitting the link; a web test proves the admin form sends the edited URL.
just check-container green (fmt + clippy -D warnings + 104 tests).

Note for the reporter

The seed URLs (https://dev.a8n.run/psa-systems/<repo>/releases) are best-effort public defaults. If the canonical release-notes location differs (different org, per-repo, or multiple repos per app), correct them in the admin applications UI - no migration needed.

Closes BUNYIP-343.

🤖 Generated with Claude Code

## What Surfaces a per-application "Release notes" link in the applications view (BUNYIP-343). Adds an admin-editable `release_notes_url` column, modelled exactly on the existing `source_code_url` field, and renders it on each application card. ## Blocker resolution The 2026-07-10 audit flagged three gaps; resolved here: 1. **The app -> URL map** is now a real column, seeded for the known hosted apps (Mokosh, Drillmark) with their public Forgejo releases page and editable from the admin UI - explicit and correctable, not guessed. 2. **Wrong path anchor**: the view is bunyip-web's Maud `app_card` fed by bunyip-api, not `src/pages/applications`. 3. **Where the association lives**: on the `applications` row. ## Changes - **Migration** adds the nullable `release_notes_url` column and seeds `mokosh` / `drillmark` (guarded on `IS NULL` so an admin edit is never clobbered). - **Column threaded** through `Application`, `ApplicationResponse`, `CreateApplication`/`UpdateApplication`, and the repository create/update SQL (appended as the highest bind parameter so existing positional params are untouched; runtime queries, no `.sqlx` regen). - **Admin form**: a "Release notes URL" field via the shared `DetailsView`, so create and edit stay in sync. The admin API already accepts it (both handlers deserialize into `Create`/`UpdateApplication`). - **app_card** renders a "Release notes" link (new tab) when set, omitting it otherwise. ## Why a stored column, not derived from Forgejo config The hosted launch tiles carry no Forgejo repo config; the download products point at the private `psa-systems-private` org (release pages not public); and one app can map to multiple repos. A derived URL would surface on ~zero real apps and could not express the mapping. The column decouples release-notes from download config and lets ops fix links without a deploy. (Chosen with the reporter.) ## Verification - Against a real Postgres: all migrations apply, the `release_notes_url` column exists, and the seed lands (`mokosh -> .../mokosh-server/releases`, `drillmark -> .../drillmark/releases`). - Unit tests cover the response carrying the column and `app_card` rendering/omitting the link; a web test proves the admin form sends the edited URL. - `just check-container` green (fmt + clippy -D warnings + 104 tests). ## Note for the reporter The seed URLs (`https://dev.a8n.run/psa-systems/<repo>/releases`) are best-effort public defaults. If the canonical release-notes location differs (different org, per-repo, or multiple repos per app), correct them in the admin applications UI - no migration needed. Closes BUNYIP-343. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

longjacksonle added 1 commit

2026-07-13 21:57:46 +02:00

feat(applications): surface per-app release-notes link in the applications view (BUNYIP-343)

E2E / Playwright against deployment (pull_request) Successful in 43s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

Check / fmt + clippy + build + tests (pull_request) Failing after 31m11s

Details

3d21e04e7b

Add an admin-editable release_notes_url per application and link it from each application card so users can see what changed. Modelled exactly on the existing source_code_url column (stored, admin-editable), which the audit confirmed is where a per-app link belongs.

Blocker resolution (the 2026-07-10 audit flagged three gaps): (1) the app -> URL map is now a real column seeded for the known hosted apps (Mokosh, Drillmark) with their public Forgejo releases page and editable from the admin UI, so the values are explicit and correctable rather than guessed; (2) the path anchor was wrong - the view is bunyip-web's Maud app_card fed by bunyip-api, not a src/pages/applications; (3) the association is stored on the applications row.

Changes: new migration adds the nullable release_notes_url column and seeds mokosh/drillmark (guarded on IS NULL so an admin edit is never clobbered); the column is threaded through the Application model, ApplicationResponse, CreateApplication/UpdateApplication, and the repository create/update SQL (appended as the highest bind parameter so existing positional params are untouched); the admin create/edit form gains a "Release notes URL" field via the shared DetailsView; and app_card renders a "Release notes" link (new tab) when the value is set, omitting it otherwise.

Deliberately a stored column, not derived from forgejo_owner/forgejo_repo: the hosted launch tiles carry no Forgejo repo config, the download products point at the private psa-systems-private org (release pages not public), and one app can map to multiple repos - so a derived URL would surface on ~zero real apps and could not express the mapping. The column decouples release-notes from download config and lets ops fix links without a deploy.

Verified against a real Postgres: all migrations apply, the release_notes_url column exists, and the seed lands (mokosh -> .../mokosh-server/releases, drillmark -> .../drillmark/releases). Unit tests cover the response carrying the column and the app_card rendering/omitting the link; a web test proves the admin form sends the edited URL. Full just check-container green (fmt + clippy -D warnings + 104 tests).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L5dcYueNHByRnWJDYoDX1W