feat(admin): show Hub/Binary/OCI surface tags on applications #142

Merged

vas2000-work merged 2 commits from feat/bunyip-99-admin-surface-tags into main

2026-06-14 05:57:11 +02:00

vas2000-work commented

2026-06-14 05:37:19 +02:00

Owner

What

Admins could not tell at a glance which distribution surfaces an application reaches. This adds three derived badges (Hub, Binary, OCI) to each app on the admin Applications list and at the top of the edit form: colored when the app is served in that surface, a muted "No X" outline when it is not.

How

A new SurfaceVisibility helper in bunyip-web/src/handlers/admin.rs derives the three predicates from AdminApplication, mirroring the canonical bunyip-domain rules so the badges cannot silently disagree with what users actually see:

Hub = is_active && is_hosted (matches ApplicationRepository::list_active_hosted).
Binary = forgejo_owner + pinned_release_tag + repo-or-package depending on artifact_source (mirrors Application::download_source / is_downloadable).
OCI = is_active + all three OCI fields set (mirrors Application::is_pullable).

The helper carries a doc comment pointing at those domain sources so a future change has a breadcrumb. None and empty/whitespace fields count as absent. Badges reuse the existing badge() component. The shared application_form gains an Option<&SurfaceVisibility> arg: the edit-GET path of a persisted app passes Some; create and error re-renders pass None.

Web-only: no bunyip-api, DTO wire, or database/migration change.

Verification

just check-container (fmt + clippy -D warnings + workspace lib tests) is green on the change: fmt clean, clippy clean, 185 tests pass.

One pre-existing, unrelated failure surfaced locally: bunyip-domain config::tests::test_config_defaults. It does env::remove_var("RUST_LOG") then asserts the default, but Config::from_env() calls dotenvy::dotenv() which reloads the developer's gitignored .env (RUST_LOG=info,bunyip_api=debug), overriding the removal. It is green in CI (clean checkout, no .env) and is untouched by this PR (web-only). Worth a separate tracking issue.

#BUNYIP-99

## What Admins could not tell at a glance which distribution surfaces an application reaches. This adds three derived badges (Hub, Binary, OCI) to each app on the admin Applications list and at the top of the edit form: colored when the app is served in that surface, a muted "No X" outline when it is not. ![surfaces]() ## How A new `SurfaceVisibility` helper in `bunyip-web/src/handlers/admin.rs` derives the three predicates from `AdminApplication`, mirroring the canonical bunyip-domain rules so the badges cannot silently disagree with what users actually see: - **Hub** = `is_active && is_hosted` (matches `ApplicationRepository::list_active_hosted`). - **Binary** = `forgejo_owner` + `pinned_release_tag` + repo-or-package depending on `artifact_source` (mirrors `Application::download_source` / `is_downloadable`). - **OCI** = `is_active` + all three OCI fields set (mirrors `Application::is_pullable`). The helper carries a doc comment pointing at those domain sources so a future change has a breadcrumb. `None` and empty/whitespace fields count as absent. Badges reuse the existing `badge()` component. The shared `application_form` gains an `Option<&SurfaceVisibility>` arg: the edit-GET path of a persisted app passes `Some`; create and error re-renders pass `None`. Web-only: no bunyip-api, DTO wire, or database/migration change. ## Verification `just check-container` (fmt + clippy `-D warnings` + workspace lib tests) is green on the change: fmt clean, clippy clean, 185 tests pass. One pre-existing, unrelated failure surfaced locally: `bunyip-domain` `config::tests::test_config_defaults`. It does `env::remove_var("RUST_LOG")` then asserts the default, but `Config::from_env()` calls `dotenvy::dotenv()` which reloads the developer's gitignored `.env` (`RUST_LOG=info,bunyip_api=debug`), overriding the removal. It is green in CI (clean checkout, no `.env`) and is untouched by this PR (web-only). Worth a separate tracking issue. #BUNYIP-99

vas2000-work added 1 commit

2026-06-14 05:37:19 +02:00

feat(admin): show Hub/Binary/OCI surface tags on applications

Check / fmt / clippy / build / test (pull_request) Successful in 1m2s

Details

0ebd98ba4c

Admins could not tell at a glance which distribution surfaces an application reaches. Add three derived badges (Hub, Binary, OCI) to each application on the admin Applications list and at the top of the edit form, colored when the app is served in that surface and a muted "No X" outline when it is not.

A new `SurfaceVisibility` helper in the web admin handlers derives the three predicates from `AdminApplication`, mirroring the canonical bunyip-domain rules so the badges cannot silently disagree with what users see: Hub = `is_active && is_hosted` (matches `list_active_hosted`); Binary = `forgejo_owner` + `pinned_release_tag` + repo-or-package by `artifact_source` (mirrors `Application::download_source`); OCI = `is_active` + all three OCI fields (mirrors `Application::is_pullable`). The helper carries a doc comment pointing at those domain sources. None and empty/whitespace fields count as absent.

Badges reuse the existing `badge()` component. The shared `application_form` gains an `Option<&SurfaceVisibility>` argument: the edit-GET path of a persisted app passes `Some`, while create and error re-renders pass `None`. No bunyip-api, DTO wire, or database change.

#BUNYIP-99

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

vas2000-work added 1 commit

2026-06-14 05:57:05 +02:00

Merge branch 'main' into feat/bunyip-99-admin-surface-tags

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

Details

Check / fmt / clippy / build / test (pull_request) Successful in 1m3s

Details

51e812c711