feat(download): consume dunite-download engine, drop hand-rolled code (BUNYIP-30) #26
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/bunyip-30-consume-dunite-download"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
Bunyip now consumes the generic
dunite-downloadengine (dunite PR #2) and the hand-rolled binary-download code inbunyip-domainis deleted. Tracks BUNYIP-30 (subtask of the BUNYIP-28 distribution story, follow-up to BUNYIP-29).Changes
dunite-downloadadded as a git dependency. The hand-rolledforgejo.rs,release_cache.rs,download_cache.rs,download_limiter.rsservices are deleted;services/mod.rsre-exports the engine types instead, plus a concreteAppDownloadCache = DownloadCache<DownloadCacheRepository>alias.moka/tokio-util/tempfiledeps dropped.DownloadCacheRepositoryandDownloadDailyCountRepositoryrewritten as stateful structs implementing the engine'sAssetStoreandDownloadCountertraits (same pattern asbunyip-oci'sOciBlobCacheRepository). The upsert keeps itsSELECT ... FOR UPDATEtransaction, satisfying the trait's documented atomicity contract.models/download.rskeeps only the API-facing response types and re-exports the engine's wire/cache models. The public/v1JSON contract is unchanged (fields still serialize asrelease_tag); bunyip-web needs no changes.artifact_source('release' | 'generic_package') andforgejo_packagecolumns + adownload_source()helper that builds the engine'sArtifactSource. A generic-packages-backed product can now be served through the same endpoints. Admin update queries andUpdateApplicationcarry the new fields.20260601000041: renamesdownload_cache.release_tagtoversion(matches the engine's source-neutral naming) and adds the new application columns.download.rs,admin.rs, andmain.rsre-pointed at the engine types (ForgejoAssetClient,ReleaseCachekeyed by fullArtifactSource,AppDownloadCache,DownloadLimiter+ Postgres counter via app_data).Dockerfile fix (pre-existing breakage)
just check-dockercould not run on main at all: the api Dockerfile still referencedcrates/bunyip-core/*paths from before the domain rename, and its dependency-cache layer had a latent stub-caching bug (deps removed but cargo fingerprints kept, soCOPY . .with older host mtimes made cargo link the real bunyip-api against stub-built empty libs -> 109 unresolved-import errors). Both fixed here so the builder stage verifies this PR end to end.Verification (rust-builder containers; no local toolchain on the dev box)
cargo check --workspace --all-targets: greenNotes
cargo clippy -D warningsandcargo fmt --checkfail on main under the rust 1.94 builder image (dead code in bunyip-web, older-toolchain formatting). Worth a follow-up issue deciding the canonical toolchain version.Replaces the hand-rolled binary-download code in bunyip-domain with the generic dunite-download engine. Bunyip now keeps only the consumer-side wiring: Postgres adapters implementing the engine's store traits, actix handlers, and routes. - bunyip-domain consumes dunite-download as a git dependency; the hand-rolled services (forgejo.rs, release_cache.rs, download_cache.rs, download_limiter.rs) are deleted and their types re-exported from the engine instead (services/mod.rs), including the concrete AppDownloadCache = DownloadCache<DownloadCacheRepository> alias. moka/tokio-util/tempfile deps dropped from bunyip-domain. - DownloadCacheRepository and DownloadDailyCountRepository are rewritten as stateful structs implementing the engine's AssetStore and DownloadCounter traits (same pattern as bunyip-oci's OciBlobCacheRepository). The upsert keeps its SELECT ... FOR UPDATE transaction, satisfying the trait's atomicity contract. - models/download.rs keeps only the API-facing response types (DownloadAsset, AppDownloadsResponse, AppDownloadGroup) and re-exports the engine's wire/cache models. The public /v1 JSON contract is unchanged: response fields still serialize as release_tag. - Application model gains artifact_source ('release' | 'generic_package') and forgejo_package, with a download_source() helper building the engine's ArtifactSource; admin update queries and UpdateApplication carry the new fields. Migration 20260601000041 renames download_cache.release_tag to version and adds the new application columns. - Handlers (download.rs, admin.rs) and main.rs wiring re-pointed at the engine types: ForgejoAssetClient, ReleaseCache keyed by ArtifactSource, AppDownloadCache, DownloadLimiter backed by the DownloadDailyCountRepository counter via app_data. - Dockerfile fix (pre-existing breakage on main, required for just check-docker to run at all): stale crates/bunyip-core paths from the domain rename are updated to crates/bunyip-domain, and the dependency-cache layer now purges all workspace-crate artifacts AND cargo fingerprints between the stub build and the real build. Without the fingerprint purge, COPY . . preserves host mtimes and cargo links the real bunyip-api against the stub-built empty libs, failing with 109 unresolved-import errors. Verification (rust-builder containers; no local toolchain): cargo check workspace green; 196 lib tests pass (bunyip-domain 18, bunyip-api 171, bunyip-oci 7); zero new clippy violations vs main (branch 31 vs main 33 pre-existing under rust 1.94); all 9 changed Rust files rustfmt-clean; docker builder stage (musl) builds the api binary end to end. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>