17 Commits

Include renames

Author	SHA1	Message	Date
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	d095e1f410	fix(ci): drop the bash-only shopt from the Linux artifact step ... "Prepare Linux artifacts" ran `shopt -s nullglob`, but the runner executes `run:` blocks with POSIX sh, where shopt does not exist. It exited 127 and failed the step -- so build-linux never uploaded, create-release (which needs all three build jobs) never ran, and v0.9.0 and v0.9.1 both compiled successfully but published nothing. The last release with assets is v0.8.2. Reproduced under busybox sh: the current block prints "shopt: not found", passes the unmatched rpm glob through literally ("cp: can't stat '.../bundle/rpm/*.rpm'"), and exits 127. Without nullglob an unmatched pattern stays literal, so test each candidate with [ -e ] instead; the same input then exits 0 with the AppImage and deb copied. traceability-check.yml already carries this rule in two places (`case` instead of `[[ == ]]`, a pipe instead of a here-string). Keeping the fix POSIX rather than adding `shell: bash` follows that convention and drops the dependency on bash being present in the builder image.	2026-08-21 13:34:20 +02:00
dtourolle	a7365b9511	fix(ci): cache the cargo registry, not the 16 GB target dir ... The runner's 74 GB disk kept filling. Measured on the box: 24 GB of act cache, 23.18 GB of it created in 20 days -- ~1.15 GB/day against a 30-day-unused / 90-day-used GC, so it could never converge. Cause: src-tauri/target (16 GB locally: 9.6G debug, 3.2G release, 2.4G android) was cached under five separate keys, all keyed on hashFiles('**/Cargo.lock'). The release script stamps the version into Cargo.lock, so all five invalidated on every chore(release) -- 32 distinct lockfile revisions in three months. - Cache only registry/index, registry/cache and git/db. registry/src is omitted as well: cargo re-extracts it from the 155 MB of .crate tarballs rather than storing 1.1 GB extracted. - Collapse the five per-job keys into one shared cargo-registry key. They existed to keep debug/release target artifacts from clobbering each other; with target uncached, registry contents are target-independent and every job wants the same crates. - Split cargo-xwin into its own key. It tracks the xwin version in the builder image, not our lockfile, so keying it on Cargo.lock was re-downloading the whole Windows SDK on every release bump. - CARGO_INCREMENTAL=0: never reused across runs, 3.5 GB of the debug dir. - Installer artifact retention 30d -> 7d; tagged releases carry the binaries anyway. Inflow drops from ~5 GB to ~150 MB per lockfile change. Tradeoff: Rust jobs now compile cold every run (~31min vs ~9min on a cache hit for the Linux release build). Most runs already paid that, since a release bump invalidated every key. sccache with a hard size cap is the way back if it bites.	2026-08-21 11:59:28 +02:00
dtourolle	8fbf4d92cb	ci: match release bundles by extension, and ship the rpm ... Renaming the app to JellyTau renamed its bundles, and the release job globbed `bundle/deb/jellytau_*.deb`. The copy was wrapped in `if [ -f ... ]`, so the rename would have dropped the .deb from the release silently — a green build producing an incomplete release. Matching by extension removes the coupling between the product name and the pipeline, and an empty dist/linux now fails the job instead of passing quietly. That `if [ -f "dir/"*.ext ]` guard was also wrong on its own terms: with more than one match, test gets extra arguments and returns false. Found while verifying the rename: the rpm has been built by every release since deb+rpm became the bundle targets, and never copied, published or documented. It ships now. Also declares the package rename. Tauri kebab-cases productName into the Debian package name, so "JellyTau" produces `jelly-tau` — a different package from the `jellytau` earlier releases installed, which would have put a second copy alongside the old one. deb now declares Replaces/Conflicts/Provides and rpm Obsoletes/Provides, verified in the built control file. TRACES: | DR-214	2026-08-20 21:01:43 +02:00
dtourolle	51d914777a	ci: fix cache-key collisions and skip duplicate release-commit test run ... The test job and build-linux shared one cargo cache key; the test job's debug artifacts claimed it first and actions/cache skips saving on an exact-key hit, so Linux release builds compiled cold every time (~31min vs ~9min for the correctly-keyed Windows job). Same collision between android-check and build-android. Give the release jobs their own keys. Also skip build-and-test.yml for chore(release) commits: the tag push triggers build-release.yml on the same commit, which runs the identical test suite, and the two ~1h workflows contended for the single runner slot.	2026-08-19 22:00:19 +02:00
dtourolle	b9dab56379	ci: enforce the checks the contributor rules already required ... Four gates that were documented but unenforced, plus the flaky test that made a full-suite run untrustworthy. Rust lint/format: CLAUDE.md has required `cargo fmt` and `cargo clippy` before every commit for as long as the rule existed, yet neither ran anywhere in CI — the requirement rested on memory alone. Both now run in build-and-test.yml and build-release.yml. rustfmt and clippy are already baked into the builder image, so nothing is installed at job time. `cargo fmt --all -- --check` is strict immediately (the tree is clean). Clippy is advisory for now: ~51 pre-existing warnings mean `-D warnings` would fail on unrelated work, so the step carries a TODO to flip the flag once the backlog clears. A compile error still fails it, so it is not a no-op. Traceability threshold: MIN_THRESHOLD sat at 50 while real coverage was 86%, so nearly half the matrix could rot before the gate objected. Ratcheted to 82 with the policy written down — it only ever goes up, and is never lowered to make a red build pass. The same figure lives in MIN_COVERAGE_PERCENT so `traces:coverage` gates locally on the same bar, and a test fails if the two drift. Dangling IDs: a TRACES comment could name any well-formed ID and the extractor accepted it silently, so typos and renames that missed a call site passed unnoticed. `bun run traces:validate` cross-checks every traced ID against the table rows in requirements.md and fails with the referencing files listed. It spans UT/IT as well, which the coverage orphan list ignores by design. This currently reports DR-189 and UT-188, which are being defined separately. Flaky offlineCatalog test: the first dynamic import of the service paid ~1s to transform its dependency graph, charged to a test body against vitest's 5s default. Alone it passed; under suite-wide contention it timed out. The import is now warmed at collection time, so no test is timing the compiler — the timeout is deliberately unchanged. The store shim also drops subscribers from module instances discarded by resetModules, which previously leaked across tests.	2026-08-16 22:51:44 +02:00
dtourolleandClaude Opus 5	3619f71aba	build: make the git tag the single source of truth for the version (DR-153) ... The version lived in four files — package.json, tauri.conf.json, Cargo.toml and Cargo.lock — that had to be hand-edited in lockstep, and the release workflow rewrote exactly one of them. A tagged build therefore produced an installer named for the tag wrapped around package metadata naming the previous release, and the Linux job, which had no version step at all, shipped whatever happened to be committed. scripts/set-version.sh now writes all four from one argument and is the only thing that does. Every release job calls it with the tag, including the Linux job that was missing one. The committed versions become a placeholder for dev builds rather than something to maintain by hand. The Android versionCode moves into the same script, unchanged in formula (1000 + major*10000 + minor*100 + patch). It stays inline-documented because the reasoning is not obvious: builds already in the field shipped code 1000, and Android refuses an update whose code is lower than the installed one, so a formula that can emit a smaller number for a newer release bricks updates irreversibly. UT-150 asserts that property directly — monotonic across an upgrade sequence, and always above the floor. Two edge cases the previous inline version got wrong: - A prerelease tag (v0.6.0-rc1) made $(( 0-rc1 )) abort the step under set -e. The suffix is stripped before the arithmetic; the manifests keep it. - CI passes "${GITHUB_REF#refs/tags/}" unconditionally, which on a branch build is still a full ref. That reached the validator verbatim and would have failed every untagged Android build; a non-tag ref now falls back to git describe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-11 21:21:58 +02:00
dtourolle	c3ead64748	ci(release): build Windows NSIS installer on tag ... Adds a build-windows job to the release workflow, cross-compiling the Windows NSIS installer from Linux via the builder image (MSVC target + cargo-xwin, no toolchain installs). Wires its artifacts into create-release alongside Linux and Android. TRACES: UR-003 | DR-004	2026-07-25 00:02:33 +02:00
dtourolleandClaude Opus 4.8	7b8a8f66e5	CI: make versionCode step POSIX sh compatible ... The runner executes workflow steps with /bin/sh (dash), which has no here-strings: `IFS='.' read -r MAJ MIN PAT <<< "$VERSION"` failed with "Syntax error: redirection unexpected" and aborted the Android release build. Parse the semver with `cut` instead, drop the GNU-only `\s` from the sed expression in favour of [[:space:]], and default any missing component to 0 so a malformed version can never emit versionCode 0. Verified under sh: 0.0.14 -> 1014, 0.0.15 -> 1015, 0.1.0 -> 1100, 1.0.0 -> 11000 (monotonic). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-18 12:23:04 +02:00
dtourolleandClaude Opus 4.8	2e479d05b3	Navigation up/back split, faster startup, and CI versionCode fix ... Navigation: - Split conflated "back" into navigateUp (deterministic route parent) and a history-safe navigateBack that tracks in-app depth via afterNavigate instead of history.length. Fixes the resume-from-background trap where a stale WebView stack left the header arrow stuck on the current page. - /library self-corrects for music/tv/movies (which have dedicated landing pages): a leftover currentLibrary no longer forces the inline content-list view, so "up"/back shows the libraries overview. Live TV / channels / other types still render inline. Startup (unblock first paint): - auth.initialize() no longer awaits security-status, player-config, or session verification before flipping isInitialized. These run fire-and-forget after the session is restored, so the library overview paints without waiting on several serial IPC round-trips. Versioning / CI: - tauri.conf.json + package.json aligned to 0.0.15 (the tag series had drifted to 0.1.0, whose formula-derived versionCode 1000 outran the v0.0.x tags). - Release workflow now pins a monotonic Android versionCode (1000 + major*10000 + minor*100 + patch) so tagged builds never downgrade below prior installs and always increase in semver order. Tests: navigation (4), auth (29), playbackMode (23) green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-17 21:12:36 +02:00
dtourolle	674c8e5cd0	ci(release): fix release-notes generation breaking jq publish step ... The release-notes echo lines used unescaped backticks, which the shell ran as command substitution; their output leaked control characters into release_notes.md, so jq failed with 'Invalid string: control characters ... must be escaped' when building the release payload. - Escape the backticks so they are literal markdown. - Remove emoji from the release-notes content (plain ASCII headings). - Handle an already-existing release (HTTP 409) by reusing its id for asset upload instead of failing.	2026-06-23 20:38:09 +02:00
dtourolleandClaude Opus 4.8	7fb866a583	ci: fix release Android build --apk flag requires explicit value ... Tauri CLI requires '--apk true'; bare '--apk' fails with "a value is required for '--apk <APK>'". The release workflow only reached this step now that checkout/container issues are fixed. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-21 20:44:23 +02:00
dtourolle	0c3ed74fe1	ci: Improvements	2026-06-21 17:38:06 +02:00
dtourolle	26286ac6e7	sign build	2026-06-20 17:37:48 +02:00
dtourolle	8f1c4bc9da	correct CI tag	2026-02-14 09:13:59 +01:00
dtourolle	e664bf4620	added tests, use specific CI	2026-02-14 09:08:49 +01:00
dtourolle	e3797f32ca	many changes	2026-02-14 00:09:47 +01:00