11 Commits

Include renames

Author	SHA1	Message	Date
dtourolle	9c75e74ea3	fix(ci): give the builder image what linuxdeploy needs for the AppImage ... The v0.10.0 release build failed in Build Linux after 16 minutes: failed to bundle project: xdg-open binary not found /usr/bin/xdg-open: No such file or directory linuxdeploy embeds xdg-open into the AppImage and aborts the whole bundle when it is absent. deb and rpm had already bundled fine; only AppImage was affected. This is the one failure tonight that building locally could not have caught, and the reason is worth writing down: a developer machine is a desktop and always has xdg-utils, so the AppImage builds there and fails on a minimal server image. The asymmetry is the bug. Every other release defect this evening was found by building locally first; this one needed the runner. xdg-utils, desktop-file-utils and zsync are added together rather than one at a time. Each round trip costs an image rebuild plus a failed release build, and those three are what linuxdeploy commonly reaches for (xdg-open, desktop-file-validate, and zsync for delta updates). Workflows move to jellytau-builder:2026.08.1, built and pushed with all three verified present inside it before this commit. ci-operations.md gains two things learned here: that an apt addition invalidates the layer above the cargo-install steps, so it is a ~20 minute rebuild rather than the ~2 minutes the trailing layer normally gives; and that Tauri's AppImage bundler downloads linuxdeploy, AppRun and two plugin scripts from GitHub during the build, so an AppImage build depends on GitHub being reachable from the runner.	2026-08-22 02:52:32 +02:00
dtourolle	f6653e6a8b	ci(security): add a supply-chain gate, checksums and an SBOM ... The project shipped signed Android builds and unsigned desktop binaries with no vulnerability scanning of any kind. Nothing checked the ~500 crate Rust graph or the JS packages against an advisory feed, and nothing checked that what we redistribute inside an MIT bundle permits it. The first cargo-deny run found eight vulnerabilities and one unsoundness -- bytes, four in rustls-webpki, time, two in quick-xml and rand -- every one of them closed by a `cargo update` nobody had a reason to run. That update is in this commit; 740 Rust tests and clippy -D warnings pass on the new lockfile. Two structural fixes matter as much as the gate itself: - deny.toml scopes the graph to the targets we actually ship. Without it the Apple targets pull in plist -> quick-xml and report two DoS advisories against a crate that is in no binary we release. Ignoring those by ID would silence them everywhere, including where they would matter; scoping makes them correctly absent. - libmpv is pinned by rev instead of branch = "master". A branch means the revision is whatever Cargo.lock happens to hold and any `cargo update` silently substitutes new upstream code -- in the one dependency that is not from crates.io and that links a C library into the player. The rev is the commit already locked, so this pins current behaviour rather than changing it. Licence findings are recorded rather than waved through. libmpv and libmpv-sys are LGPL-2.1, satisfied here by dynamic linking against the system library; deny.toml carries the two obligations that follow (keep the linkage dynamic, ship libmpv's licence text with any bundle carrying the .so). MPL-2.0 crates are file-level copyleft and fine unmodified. Releases now publish SHA256SUMS (verified in-job with `sha256sum -c` before upload) and a CycloneDX SBOM for both halves, so "does this release contain <vulnerable crate>?" has an answer that is not "rebuild the tag and re-resolve it". Workflows pin jellytau-builder:2026.08 instead of :latest. While every job said :latest, rebuilding the image changed what every build compiled against, including rebuilds of old release tags. Also folded in, because both were the same class of problem: - publish-docs.yml downloaded mdBook from GitHub releases into /usr/local/bin at job time -- a toolchain install in CI, which CLAUDE.md explicitly forbids, and a hard dependency on GitHub's CDN at publish time. It is in the builder image now. - extract-traces.ts only ever read .ts/.svelte/.rs, so every requirement implemented by *configuration* was invisible to the matrix that measures it. DR-205, DR-206, DR-207 and DR-215 all carry TRACES comments nothing read, and each counted as uncovered while being covered. Coverage was really 90%, not 88%; MIN_THRESHOLD moves to 89 accordingly. CI workflows stay excluded and there is a test saying why: traceability-check.yml quotes "a TRACES: comment" beside deliberately-undefined example IDs, which the extractor would read as real traces and then fail its own dangling-ID check. Supply-chain requirement is DR-216. 🔴 The builder image must be rebuilt and pushed (scripts/build-builder-image.sh 2026.08) before this reaches master -- the workflows now name a tag and tools that do not exist in the registry yet.	2026-08-21 18:25:38 +02:00
dtourolle	4af6ed0f98	build(rust): pin the toolchain to 1.97.1 for dev and CI ... The Rust toolchain was unpinned on both sides, and the two sides had drifted five releases apart: the CI builder image ships rustc 1.97.1, the development machine was on 1.92.0. Clippy's lint set and rustfmt's output both change between releases, so a green `cargo clippy` / `cargo fmt --check` locally said nothing about CI and vice versa — which is the reason the clippy gate could not be trusted enough to turn on. src-tauri/rust-toolchain.toml pins channel 1.97.1 with the rustfmt and clippy components. Deliberately no `targets` list: that would make rustup fetch the Android and Windows std libraries on every plain `cargo test`, including on machines that never cross-compile. The image already has them. Dockerfile.builder installs that exact version instead of "latest stable at rebuild time", and prints rustc/clippy versions so a mismatch is visible in the build log. The pin only becomes authoritative once the image is rebuilt and pushed (scripts/build-builder-image.sh). Until then CI still runs whatever rustc the current image has, and if that is not 1.97.1 rustup will download the pinned toolchain at job time — a toolchain install in CI, which CLAUDE.md forbids. Both files carry that warning next to the version. Note: the clippy step in .gitea/workflows/build-and-test.yml is left advisory here; tightening it wants a warning count measured on 1.97.1 first.	2026-08-20 19:35:51 +02:00
dtourolleandClaude Opus 5	50934e2ac6	ci(android): ship Gradle in the builder image instead of downloading it ... The release APK job died at the Gradle wrapper step, after the 11-minute Rust compile had already succeeded: Downloading https://services.gradle.org/distributions/gradle-8.14.3-bin.zip java.net.SocketException: Unexpected end of file from server `tauri android init` regenerates gen/android with a wrapper pointing at services.gradle.org, so every Android job re-downloaded ~130MB of Gradle at build time. That is slow on a good day and a hard build failure when the CDN drops the connection mid-transfer. It was also a standing violation of the rule that every build tool must already live in the builder image. Dockerfile.builder installs Gradle 8.14.3, keeping both the unpacked distribution (on PATH) and the original zip under /opt/gradle/dist. A `gradle --version` smoke-test fails the image build on a bad version rather than letting CI discover it. sync-android-sources.sh then repoints the regenerated wrapper at that local zip, which is the established place for fixing up the generated project. It parses the version the wrapper actually requests, so a future Tauri Gradle bump logs "not in image, will download" instead of pointing at a missing file. On dev machines /opt/gradle/dist does not exist and the properties file is left untouched. Verified by running the project's own wrapper jar inside a network namespace with no connectivity: it resolved and unpacked the local zip to 100% and proceeded into build-script evaluation. Note: this is inert until the builder image is rebuilt and pushed (scripts/build-builder-image.sh). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 07:47:43 +02:00
dtourolle	742ad88a29	feat(build): cross-platform desktop packaging; bump to 0.1.0 ... Adds Docker-based packaging for Linux desktop (deb/rpm), Arch (.pkg.tar.zst via makepkg), and Windows. Windows cross-compiles from Linux via the official Tauri path — the x86_64-pc-windows-msvc target driven by cargo-xwin — and produces an NSIS installer (nsis via tauri.conf.json targets, since the CLI rejects --bundles nsis on a Linux host). Verified end to end: builds jellytau.exe + jellytau_x64-setup.exe. Unifies everything on one registry builder image (Dockerfile.builder): Android SDK/NDK, rpm/file, clang(+clang-cl)/lld/llvm/nsis, cargo-xwin and the msvc target. Packaging tools sit in a trailing layer so tool changes rebuild in ~1min instead of ~15. Desktop stages are thin FROM ${BUILDER_IMAGE} layers; Arch uses a separate archlinux image. CLAUDE.md: CI must install no system toolchains — everything lives in the image. Bumps version 0.0.18 -> 0.1.0 (Windows support + webview audio + equalizer). TRACES: UR-003, UR-005 | DR-004	2026-07-24 23:49:50 +02:00
dtourolle	a5b6266a6d	Permanent CI fix	2026-06-21 10:48:26 +02:00
dtourolle	57ff364f54	Add dep to docker file	2026-06-20 18:20:38 +02:00
dtourolle	46b9d328ab	More CI fixes	2026-06-20 16:15:33 +02:00
dtourolle	0738ef10ec	More clean up	2026-06-20 15:38:26 +02:00
dtourolleandClaude Haiku 4.5	6d1c618a3a	Implement Phase 1-2 of backend migration refactoring ... CRITICAL FIXES (Previous): - Fix nextEpisode event handlers (was calling undefined methods) - Replace queue polling with event-based updates (90% reduction in backend calls) - Move device ID to Tauri secure storage (security fix) - Fix event listener memory leaks with proper cleanup - Replace browser alerts with toast notifications - Remove silent error handlers and improve logging - Fix race condition in downloads store with request queuing - Centralize duration formatting utility - Add input validation to image URLs (prevent injection attacks) PHASE 1: BACKEND SORTING & FILTERING ✅ - Created Jellyfin field mapping utility (src/lib/utils/jellyfinFieldMapping.ts) - Maps frontend sort keys to Jellyfin API field names - Provides item type constants and groups - Includes 20+ test cases for comprehensive coverage - Updated route components to use backend sorting: - src/routes/library/music/tracks/+page.svelte - src/routes/library/music/albums/+page.svelte - src/routes/library/music/artists/+page.svelte - Refactored GenericMediaListPage.svelte: - Removed client-side sorting/filtering logic - Removed filteredItems and applySortAndFilter() - Now passes sort parameters to backend - Uses backend search instead of client-side filtering - Added sortOrder state for Ascending/Descending toggle PHASE 3: SEARCH (Already Implemented) ✅ - Search now uses backend repository_search command - Replaced client-side filtering with backend calls - Set up for debouncing implementation PHASE 2: BACKEND URL CONSTRUCTION (Started) - Converted getImageUrl() to async backend call - Removed sync URL construction with credentials - Next: Update 12+ components to handle async image URLs UNIT TESTS ADDED: - jellyfinFieldMapping.test.ts (20+ test cases) - duration.test.ts (15+ test cases) - validation.test.ts (25+ test cases) - deviceId.test.ts (8+ test cases) - playerEvents.test.ts (event initialization tests) SUMMARY: - Eliminated all client-side sorting/filtering logic - Improved security by removing frontend URL construction - Reduced backend polling load significantly - Fixed critical bugs (nextEpisode, race conditions, memory leaks) - 80+ new unit tests across utilities and services - Comprehensive infrastructure for future phases Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-02-13 23:34:18 +01:00
dtourolleandClaude Haiku 4.5	544ea43a84	Fix Android navigation and improve UI responsiveness ... - Convert music category buttons from <button> to native <a> links for better Android compatibility - Convert artist/album nested buttons in TrackList to <a> links to fix HTML validation issues - Add event handlers with proper stopPropagation to maintain click behavior - Increase library overview card sizes from medium to large (50% bigger) - Increase thumbnail sizes in list view from 10x10 to 16x16 - Add console logging for debugging click events on mobile - Remove preventDefault() handlers that were blocking Android touch events These changes resolve navigation issues on Android devices where buttons weren't responding to taps. Native <a> links provide better cross-platform compatibility and allow SvelteKit to handle navigation more reliably. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>	2026-01-27 16:04:57 +01:00