52 Commits

Include renames

Author	SHA1	Message	Date
timothy	c5369b1d69	ci(412): sample true peak-anon in the test job, not cache-inflated memory.peak ... The test-job memory instrument (#411) reported memory.peak — the high-water mark of memory.current, which charges reclaimable page cache to the cgroup. A build does heavy NuGet/npm/obj/bin/coverage I/O, so cache can dominate the peak, and page cache is reclaimed under a tighter cap rather than OOM-killed. Sizing a per-job cap (server-management#604) off memory.peak therefore inverts the decision. The OOM-forcing quantity is peak anon, which the kernel exposes no counter for and which the end-of-job split misses (a job that peaks mid-dotnet-test then frees reports a low anon). New scripts/ci-peak-anon.sh: a `start` step (before Build/Test/Coverage) launches a detached background sampler tracking the high-water mark of cgroup anon; a `report` step (last) stops it and prints the sampled peak anon as the headline, keeping memory.peak + end-of-job split as a cache-inflated ceiling and reference. Both continue-on-error + fail-open so they never redden a build. Validated on bumblebee: survives step-boundary re-execs, catches a transient 2.5 GiB anon spike the snapshot reports as 0, stops cleanly on kill, degrades gracefully. Compiler-server A/B (swap-off, sampled peak-anon, n=2 interleaved): OFF (CI config) ~5.84 GiB consistent; ON (defaults) 6.3-7.6 GiB, always higher, + a ~3 GiB resident VBCSCompiler. Disabling the servers is worth it, but OFF sits right at 6 GiB for the build phase alone and the test job adds test+coverage, so #406's "budget loosens well under 6 GiB" premise is not supported. Size the cap off the live test-job sampler. Docs: ci-cd.md instrument section rewritten (peak-anon headline + A/B table + premise verdict); decisions.md entry added. No .cs touched. fixes #412	2026-07-19 20:49:08 +02:00
timothyandClaude Opus 4.8	33657b4753	docs(469): sweep remaining stale format-job cost/memory claims (review) ... Cold adversarial review (MERGEABLE) flagged two spots still describing the pre-#469 heavy `format` job as current, plus a wording imprecision: - ci-cd.md CI-lane table row: annotate `format` runtime 37s → ~0.5s (#469). - ci-cd.md #406 memory narrative: note the 3.95 GiB Roslyn heap is now moot (folder mode loads no workspace); api-docs remains the lane's real consumer. - Precise the coverage mechanism in ci-cd.md + decisions.md: the naming rule passes the full gate because naming violations have no `dotnet format` batch code-fixer (so `--verify-no-changes` sees no change), not merely a severity floor. Docs-only; no workflow/hook logic change from the reviewed commit. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 19:34:43 +02:00
timothyandClaude Opus 4.8	eafb2e39e2	perf(469): format gate uses dotnet format whitespace --folder (~480s → ~0.5s) ... The blocking `format` CI job and the Husky pre-commit hook verified changed .cs files with `dotnet format ErsatzTV.sln --no-restore --verify-no-changes --include <files>`. `--include` only narrows *which* files are checked, never what gets loaded: the full recipe loaded the ~10-project MSBuild workspace and built a Roslyn compilation per project before checking a single line (~480s locally, whole-solution). Switch both to `dotnet format whitespace . --folder --verify-no-changes --include <files>`, which treats the tree as a plain folder of files, skips MSBuild/Roslyn entirely (~0.5s), and needs no `dotnet restore` (NuGet-cache + Restore steps removed). Coverage is unchanged: folder mode reads .editorconfig and enforces exactly the gate's purpose — whitespace + charset (BOM). Proven non-vacuous (error WHITESPACE on a trailing-space line, error CHARSET on a prepended BOM, exit 0 clean). The full gate never enforced the style/analyzer pass either — a warning-severity naming violation passes the full solution format (exit 0) — and the analyzers that must block (NU1904, S3981) are enforced at compile via WarningsAsErrors, not by this job. Docs: ci-cd.md Formatting section + the obsolete #406 memory note; decisions.md. fixes #469 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 18:33:31 +02:00
timothyandClaude Opus 4.8	038703fe67	test(444): deterministic functional-E2E for the playout-build lock 409 + isLocked projection ... Adds "Flow C" to scripts/e2e-functional.sh, the last deferred lock-contention flow from #363. A playout build is enqueued onto the single-consumer WorkerService channel and the trigger returns before BuildPlayoutHandler acquires the lock, so an accepted trigger does not prove the lock is held. Flow C makes it deterministic: seed a Classic Flood schedule over a few short ffmpeg episodes, crank PlayoutDaysToBuild=5 (~43k items ~= ~1s build), then POLL GET /playouts/{id} until isLocked:true before firing. Asserts PUT /playouts/{id} -> 409, reset -> 409, and the list-projection isLocked:true while locked; then isLocked:false + PUT -> 200 after the build (proving the 409 is lock-specific). Each racing assertion is guarded so a build that finishes mid-flight degrades to an advisory skip, never a false red; the whole flow self-skips without ffmpeg or if the build is never observed locked. Sized by measurement on a fresh instance -- going wider is counter-productive (a 777k-item build saturates the single worker with post-build gap/overlap jobs). Verified green across 6 fresh-instance runs; cold adversarial review MERGEABLE. Docs: docs/e2e-local.md + docs/ci-cd.md updated to describe Flow C and drop it from the "deferred" lists. fixes #444 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-19 17:37:50 +02:00
timothyandClaude Opus 4.8	dd55f00ed4	docs(420): sharpen the skip's honest hit-rate (rebase-before-merge) + cite live combined-status check ... Review nits from the scoped #420 review. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 20:53:23 +02:00
timothy	922b1ef53c	docs(398,420): document the #420 skip + record build-once measured-and-rejected	2026-07-18 20:53:23 +02:00
timothyandtimothy	ab8e5d7a91	ci(338): distinguish ZAP warning (exit 2) from failure (exit 1) in security-scan (#452) ... Co-authored-by: Timothy <timothy.look@gmail.com> Co-committed-by: Timothy <timothy.look@gmail.com>	2026-07-18 16:16:41 +00:00
timothyandClaude Opus 4.8	a1b75c1f2c	docs(363): sweep the scan-flow drift the re-review caught ... The fix commit softened the script's scan-409 wording + dropped ?deep=true but left the docs describing the old behavior. Match them: - docs/e2e-local.md: POST .../scan (no ?deep; note local scans always ForceScan) + "409, deterministic bar a tiny residual TOCTOU gap" (was "guaranteed 409") - docs/ci-cd.md: same "guaranteed 409" -> "409 (deterministic bar ...)" Docs-only; harness behavior unchanged (still 38/38 green, deterministic). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 15:44:47 +02:00
timothyandClaude Opus 4.8	4345180a56	review(363): robustness + wording fixes from cold review ... - check seed_library_path succeeded (print lastrowid) so a silent seeding failure surfaces as a FAIL instead of degrading Flow A to an advisory skip with no diagnostic (Medium) - anchor the scan-status match to '"libraryId":2,' so it can't substring-match "libraryId":20/23 if the suite ever creates more libraries (Low) - drop the no-op ?deep=true (local scans always ForceScan; deep only affects Plex/Jellyfin/Emby) + note why (Low) - soften "guaranteed 409" for the scan flow to note the tiny residual TOCTOU gap the multi-second scan covers; Flow B stays race-free by construction (Low) - correct the "WAL tolerates a second writer" wording to the real reason (the busy-timeout retry serializes the writer) in the script + both docs (Nit) - use TEST-NET-1 192.0.2.1 (RFC 5737) instead of RFC1918 10.255.255.1 for the non-routable Jellyfin address (Nit) Re-verified: fresh-instance harness runs green (38/38), lock section deterministic. Functional E2E CI job already green on the prior head. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 15:33:39 +02:00
timothyandClaude Opus 4.8	8a85f9ddb5	test(363): functional-E2E harness — add deterministic scan-lock + collections-lock 409 flows ... Extends scripts/e2e-functional.sh with the two IEntityLocker 409 contracts the first cut (ersatztv#299) deferred as "racy", made DETERMINISTIC by firing the racing request only once the lock is provably held (no sleep-and-hope): - library-scan "already scanning" 409: seed ~60 tiny ffmpeg clips into the built-in Shows library so the scanner subprocess runs a few seconds, poll GET /libraries/scan-status until the library is active (that window is a strict subset of the scan lock's held window — StartScan after LockLibrary, EndScan before UnlockLibrary), then a second POST .../scan is a guaranteed 409. Self-skips (advisory) when ffmpeg is absent. - external-collections "already scanning" 409: seed a Jellyfin media-source row pointing at a non-routable address so the background sync hangs and the per-family lock stays held; the lock is taken synchronously before the 202, so the 202 proves it held. collections-scan-status corroborates; unknown source 404. Seeding uses python3's stdlib sqlite3 (already a harness dep) to insert rows the API can't create (LibraryPath, media-source); WAL mode tolerates the second writer. No new CI step/dependency — ffmpeg ships in the toolchain image. Verified: 4/4 fresh-instance runs green (38/38), lock section deterministic. Still deferred to #363 follow-ups: the playout-build lock 409 + isLocked projection (#215) and the UI-interactive Playwright flows. Docs updated same PR: docs/e2e-local.md, docs/ci-cd.md, the functional-e2e job comment in .gitea/workflows/docker-build.yml. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 15:17:21 +02:00
timothy	082124f706	docs(416): note shallow-checkout FETCH_HEAD/two-dot fix (ci-cd + decisions) ... Refs #416	2026-07-17 22:02:06 +02:00
timothy	92bb63b6da	docs(416): document docs-only CI skip ... ci-cd.md gains a 'Docs-only skip' section + triggers-table note; decisions.md records the decision. Cross-refs the separate PR-vs-main rerun redundancy (#420) and the within-run triple build (#398). Refs #416	2026-07-17 19:44:25 +02:00
timothyandClaude Opus 4.8	469d725559	ci(406): apply the memory-swap rule to our own two sites; stop leaning on the peak reading [decisions-edit] ... Re-review of the fix commits came back MERGEABLE with three findings worth acting on. MEDIUM -- the PR documented a standing rule ("--memory without --memory-swap silently grants 2x in swap") and then didn't apply it to the two sites this repo owns: docker-build.yml's smoke container and scripts/migration-smoke.sh, both `--memory 2g` with no --memory-swap. Pre-existing rather than a regression, but a rule you don't follow in your own repo isn't a rule. The migration-smoke one matters most: it runs on the PROD host in the release path, so a runaway migration should die against its cap rather than quietly swap out the box serving media. LOW -- and this is the important one: the docs leaned "peak 8305 MiB is probably mostly reclaimable cache". An independent probe (full solution build, same CI image, shared compilation off) measured peak 9457 MiB / anon 7134 MiB / file 421 MiB. ANON DOMINATED. Having verified the *mechanism* (peak overstates because it counts page cache), I guessed the *magnitude* in the direction I preferred -- the exact failure this entry criticises, committed inside the entry criticising it. Corrected in ci-cd.md, decisions.md and on server-management#604 (where the previous comment could have led to an unsafe 6g cap). Consequences now recorded honestly: a 6g cap looks UNSAFE, #570's "6g proved too tight" is the rule not an outlier, and #406's premise ("if this brings peak RSS well under 6 GiB the whole budget loosens") is looking DEAD -- the 7134 MiB anon was measured with shared compilation already off. The switches remain right; the looser budget they were meant to buy does not follow. NIT -- dropped the unverified claim that this also disables the Razor build server. The UseRazorBuildServer -> UseSharedCompilation fallback is .NET 5-era; Razor has been an in-process source generator since .NET 6, so there is likely no separate server to disable on .NET 10. Unverified, zero impact, so it has no business in a doc arguing for measurement over assumption. [decisions-edit]: the touched docs/decisions.md lines were added by this PR's own earlier commits, not settled entries on main -- net vs origin/main remains a pure insertion (0 deletions, verified). Also the sanctioned reason: the entry was factually wrong (see LOW). Verified: both workflows parse; migration-smoke.sh passes bash -n; the parsed mysql option string is `--memory=2g --memory-swap=2g --cpus=2`. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 16:13:39 +02:00
timothyandClaude Opus 4.8	7859510c78	ci(406): report anon/file split — memory.peak counts page cache, not just RSS [decisions-edit] ... The peak-memory step from the previous commit worked on its first real CI run and immediately produced a number that would have led #604 to the WRONG decision: peak container memory: 8305 MiB (8708448256 bytes, from /sys/fs/cgroup/memory.peak) Read naively that says "the test job needs 8.1 GiB, so the 10g cap must stay and #406's 'the budget loosens' premise is dead". That reading is probably wrong, because `memory.peak` is the high-water mark of `memory.current`, which charges PAGE CACHE to the cgroup as well as anonymous memory. It is not peak RSS, and a build job does heavy NuGet/npm/obj/bin/coverage I/O. Proven on bumblebee -- a container with ZERO anonymous memory that merely reads an 800MB file: memory.peak : 826 MiB anon : 0 MiB file : 800 MiB This inverts the decision: page cache is RECLAIMED under a tighter cap, not OOM-killed, so a large peak that is mostly `file` is NOT evidence that the cap must stay high. `anon` is what forces an OOM. So the step now prints the anon/file split and says, in the log and the docs, to size caps on anon rather than peak. Honest about what this still isn't: the split is read at end-of-job, so it is the composition then, not at the peak instant -- a job peaking mid-`dotnet test` and freeing after would under-report anon. Sampling a true peak-anon is ersatztv#412, filed with the options. Also recorded there and in ci-cd.md: there is NO pre-change baseline from this instrument (7.8 GB VBCSCompiler was measured host-wide across concurrent jobs, not inside one job container), so #406's premise is neither confirmed nor killed yet. What IS established: no persistent compiler server survives a build, and migrations is green with mysql capped at 2g with swap disabled. The irony is the point, and it is now written into decisions.md: this repo's CI perf work keeps stating numbers from plausibility rather than measurement (#390's "2-4min" apt-ffmpeg estimate; real 110s). Measuring the wrong quantity precisely is the same failure wearing a lab coat -- and it bit this very change, whose whole purpose was to replace an inherited number with a measured one. Verified: shellcheck clean; the real step body run inside a --memory=2g container under `bash -e -o pipefail` reads memory.peak, prints the split, writes the step summary, exits 0; and it degrades to a skip + exit 0 where no cgroup file exists. [decisions-edit]: the modified docs/decisions.md lines are ones THIS PR added in its own earlier commits, not a settled entry on main -- net vs origin/main is still a pure insertion (0 deletions, verified). It is also the sanctioned reason: the entry as written was factually wrong about what memory.peak measures. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:53:24 +02:00
timothyandClaude Opus 4.8	04e3a5249d	ci(406): disable swap on the capped mysql; fix peak-step placement and failure mode [decisions-edit] ... Review fixes from the cold adversarial pass on PR #411. Verdict was MERGEABLE, but one HIGH is a genuine defect worth the round-trip. [decisions-edit] rationale: the 12 "modified" lines in docs/decisions.md are lines THIS PR added in its own previous commit (e33205e8), not a settled entry on main. The hook diffs against HEAD; net against origin/main this file is still a pure insertion (65 added, 0 deleted -- verified, and CI's decisions-guard diffs against the PR base). It is also the sanctioned reason regardless: the entry as first written contained a factual error (see HIGH below). HIGH -- `--memory=2g` alone silently grants 2g of SWAP as well. Docker defaults an unset --memory-swap to 2x --memory. Verified live on bumblebee: `--memory=2g` alone gives memory.max=2147483648 AND memory.swap.max=2147483648; adding `--memory-swap=2g` gives memory.swap.max=0. Capping RAM while permitting swap is close to the worst outcome on the one host whose swap thrash is the entire reason for the cap -- and a swapping mysqld mid-DDL is exactly the pathology behind the known `Command Timeout expired` migrations flake, so the naive cap could have made that flake worse rather than better. The comment promising "if this ever OOM-kills the service" described a failure mode that would not have happened first: it would have swapped, silently. Now --memory-swap=2g (swap off); prefer a loud OOM over silent degradation. The same 2x applies to the runners' 10g job slots (10 GiB RAM + 10 GiB swap each), which is a plausible direct mechanism for the incident's 21 GiB swapped. That is #604's boundary -- reporting it there. MEDIUM -- `if: always()` does not make a step advisory. It controls whether the step RUNS, not whether its failure fails the job, and defaults.run.shell: bash means -e is on, so a failed cat/redirect in an informational step could redden a green test job. Use continue-on-error: true, matching the neighbouring Coverage summary step. MEDIUM -- the peak step must run LAST. memory.peak read at step N reports the peak only up to N, so sitting before Coverage summary excluded reportgenerator's memory -- under- reporting the very number #604 sizes caps on. Moved after it. LOW -- dependency-scan.yml gets the env too; workflow env does not cross workflow files, and that one runs unattended on a cron against the prod media host. NIT -- Dockerfile ENV moved below the openapi-generator wget: an ENV invalidates every layer under it, and that ~30MB download is deliberately ordered early to stay cached (#190). Nothing between it and restore compiles, so this placement is free. NIT -- docs no longer imply this shrinks `format`. dotnet format loads Roslyn in-process via MSBuildWorkspace and never spawns csc, so its 3.95 GiB is untouched; sizing the small lane on the assumption it shrank would be a trap. Also record honestly that 543 MiB is init+idle rather than the 787-migration replay (so 2g is a measured floor + headroom, not a measured ceiling -- the migrations job going green is what validates it) and that --cpus=2 is judgement with no measurement behind it. The entry criticises dressing estimates as measurements; it should not do that itself. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:36:18 +02:00
timothyandClaude Opus 4.8	e33205e8eb	ci(406): disable persistent compiler servers, cap the mysql service, report peak RSS ... Refs #406, server-management#604. Items 1 and 2 of #406 (item 3 landed in PR #407). Root cause of the 2026-07-17 bumblebee incident (load 340, 21 GiB swapped, prod media down until reboot) is CI-induced memory pressure, and the largest single consumer was Roslyn's persistent VBCSCompiler at 7.8 GB RSS. It is a compiler *server*: it outlives the build that started it to keep its heap warm for the next one. In CI there is no next build -- each job container is torn down at the end of the run -- so it is pure cost, and it is the actual reason each job needed a 10 GiB cap. 1. Disable the compiler servers via the workflow's top-level env (UseSharedCompilation, DOTNET_CLI_USE_MSBUILD_SERVER, MSBUILDDISABLENODEREUSE). MSBuild surfaces env vars as properties and only defaults UseSharedCompilation when empty, so the env var wins and every dotnet call is covered without touching each call site. Also set as ENV in the Dockerfile's SDK stage: the workflow env reaches runner-side jobs only, and the `build` job compiles inside `docker build` where it does not propagate -- that is the job server-management#570 measured pegging 5.999/6 GiB, so it is the one that most needs this. Build stage only; the final image is FROM runtime-base, so nothing lands in the shipped image. Verified locally: a default build leaves 1 VBCSCompiler alive, the same build under these vars leaves 0, and ErsatzTV.sln still builds clean (0 errors). Trade-off: csc runs per project instead of via the server, costing some build time. 2. Cap the mysql service (--memory=2g --cpus=2). A runner's container.options applies to the job container ONLY: a live migrations job reported HostConfig.Memory=10737418240 for the job and mem=0 nanocpus=0 for its mysql service, i.e. unbounded. 2g is sized on measurement -- mysql:8.4 with this exact env peaked at 543 MiB during init, 481 MiB idle (probed on bumblebee) -- not on inheritance. Also add a `Report peak container memory` step to the test job (cgroup memory.peak, always(), never fails a build). server-management#604 sizes both runners' caps on that number and it was inherited rather than measured; now every run reports it. Docs: ci-cd.md gains the compiler-server + services-cap sections and the lane table is corrected (PR #407 reverted the #390 lane move without updating it). decisions.md records all three, incl. the standing rule that a services: container never inherits a cap. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 15:22:31 +02:00
timothy	07048b8c96	ci(390): address cold review — pin-drift guard, honest cron, doc fixes ... Cold adversarial review findings: - MEDIUM (Renovate generates pin drift): add a blocking ci-image-pin job. Renovate manages docker/ci/Dockerfile's base pins but cannot bump an opaque :<sha> in container.image, so a base bump would publish a new image, test the OLD one, and merge with the Dockerfile disagreeing with the pin. The guard fails when the pin isn't the last commit to touch docker/ci, or when the 5 jobs pin different tags — making the documented two-step enforced rather than remembered. - MEDIUM (cron was a no-op): the weekly rebuild updated nothing (jobs pin :<sha>) and buildcache would have restored the apt layer verbatim, collecting none of the base updates it existed for. Added no-cache on the schedule path and rewrote the comment to state what it actually is: a build canary + a fresh :latest for the next bump. - LOW: FFMPEG_TAG was referenced in the Dockerfile + docs but never existed (the FROM is hardcoded); reworded both. - LOW: paths: filtered the exact file while the docs claimed docker/ci/** — use **. - NIT: docs oversold ENTRYPOINT reset as a gotcha; act overrides it anyway. Marked defensive. Refs #390	2026-07-17 09:34:46 +02:00
timothy	84756eebab	ci(390): default run steps to bash — act_runner uses sh inside container: ... The migrations job died in 0.13s with 'set: Illegal option -o pipefail'. Root cause: inside a container: act_runner does not default to bash, it falls back to 'sh -e {0}' (dash), since it cannot assume bash exists in an arbitrary image. Every multi-line script in this workflow is bash (set -o pipefail, arrays, shopt, mapfile), so dash fails them immediately. The format job passed only because it already declared shell: bash explicitly. Declare it once at the workflow level instead of per step; non-container jobs already defaulted to bash, so nothing changes for them. Documented in docs/ci-cd.md as a container gotcha — it surfaces only once a job is containerized and does not look like a shell problem. Refs #390	2026-07-17 09:26:43 +02:00
timothy	afa42b0b6f	ci(390): run toolchain jobs in the shared CI image; drop 110s apt-ffmpeg; rebalance lanes ... Converts test/migrations/functional-e2e/api-docs/format to run inside ersatztv-ci:6a9e27c via container:, removing per-run setup-dotnet, setup-node, apt-get ffmpeg and dotnet tool install. NuGet/npm caches stay (project deps); setup-node's implicit npm cache is replaced with an explicit actions/cache. Rolled-up wins found while auditing every job's steps (evidence in #390): - Drop the apt-ffmpeg step (110s/run). It was never load-bearing: the app's only startup ffmpeg touch is a LogWarning from FFmpegLocatorService, and the harness drives curl-only contracts that never transcode. The image ships prod-identical ffmpeg 8.1.2 anyway, which #299's seeded-media follow-ups will need. - Bake dotnet-ef + reportgenerator into the image (2 per-run tool installs gone; versions now live in one tracked place). - Move api-docs (5s) and format (37s) to the idle 'small' lane — they were each queueing ~29min in the saturated ubuntu-latest lane. Also drops that lane from 5 jobs to 3. Only possible because container: makes them self-contained. Measured, not assumed: the image itself is worth only ~15-40s/job. The dominant costs are queue wait (server-management#604) and 742s of redundant compilation (#398) — both filed rather than silently bundled here. Refs #390	2026-07-17 09:16:04 +02:00
timothy	dbd4bb43f7	Merge pull request 'feat(analyzers): enable incremental latest-All enforcement' (#375) from feat/15-analyzer-promotion into main	2026-07-16 20:19:07 +00:00
timothyandClaude Opus 4.8	a2c056dd7a	docs(release): prepare v26.9.0 promotion [decisions-edit] ... Consolidate docs/decisions.md (1923 -> 1028) by extracting four cohesive topic clusters into docs/decisions/ (optimistic-concurrency, api-auth-security, release-ci-governance, spa-modularization) — content relocated verbatim (lossless; all rationale + reversals preserved), main Index rebuilt to reference the topic files plus the remaining in-file entries, docs/README.md points back at the decisions Index. Add the v26.9.0 row to the ci-cd.md version table. refs #340 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 22:17:23 +02:00
timothyandCodex	10ae885b47	fix(analyzers): preserve non-CPM and image builds ... Guard analyzer package references for the inline-version MCP tool and copy the SDK suggestion baseline into the Docker build context before restore. Refs #15 Co-Authored-By: Codex <codex@openai.com>	2026-07-16 21:52:27 +02:00
timothyandCodex	8f90cea5cc	feat(analyzers): enable incremental latest-All enforcement ... Centralize SDK and threading analyzers, baseline the .NET 10 All rule inventory at suggestion severity, and promote S3981 repo-wide. Fix the always-true worker count predicate and cover the idle/active branches. Fixes #15 Co-Authored-By: Codex <codex@openai.com>	2026-07-16 21:52:27 +02:00
timothyandClaude Opus 4.8	e78aa01c05	ci(coverage): exclude generated EF migrations to stop coverage OOM (exit 137) ... The shared Build & test job OOM-killed (exit 137) with coverage enabled: the whole-solution Architecture.Tests process instruments both EF migration folders (~2.59M generated lines vs ~200k authored), ballooning coverlet's in-memory hit-count arrays past the runner's limit. Add coverlet.runsettings excluding **/Migrations/*.cs (+ generated/compiler attributes) and pass it via --settings on the Test step. This cuts the instrumented surface ~126x (2,510,185 -> 19,963 coverable lines in the Architecture.Tests process, verified locally) and makes the reported percentage reflect authored code. Documented in docs/ci-cd.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 19:03:54 +02:00
timothyandClaude Opus 4.8	2090f7865c	ci(coverage): collect code coverage and publish a summary (refs #15) ... #15 scope item 4 ("collect with coverlet and publish a summary; decide on a floor later"). coverlet.collector was already referenced by four of the six test projects but the CI Test step never passed --collect and nothing summarized the result. - Add coverlet.collector to ErsatzTV.Core.Tests and ErsatzTV.Tests so coverage is uniform across all *.Tests projects. - CI Test step now runs --collect:"XPlat Code Coverage" --results-directory ./coverage, then a best-effort Coverage summary step merges the per-project Cobertura reports with ReportGenerator (TextSummary to the log, MarkdownSummaryGithub to the job step summary). No floor is enforced yet; continue-on-error keeps it purely informational. - gitignore /coverage/; document the step in docs/ci-cd.md (test job). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 18:45:32 +02:00
timothyandClaude Opus 4.8	0d7803079c	ci: add advisory functional-E2E curl harness (fixes #299) ... Codify the manual live-E2E curl flows sessions have been re-running by hand into a CI regression net: a new `functional-e2e` job boots the app from source (via scripts/e2e-local.sh, parameterized for Release) and drives scripts/ e2e-functional.sh against it. First-cut contracts (all curl-only, deterministic, no seeded media/ffmpeg/browser): - legacy->SPA redirect sweep + the /api,/artwork never-redirect exemption - auth/CSRF/security-stamp flow (setup-claim, read-gate, CSRF, login, logout+revoke) - library-scan status contract (404/202/scan-status) - optimistic-concurrency If-Match/412 round-trip Advisory by design (separate job, not a `build` dependency, not a required check) so a functional-E2E flake can't block the unit-test gate; promote once proven, mirroring the migrations-job rollout. SQLite default -> no DB service. Deferred to #299 follow-ups (need scanner+seeded media or a browser to be deterministic): the racy 409 re-trigger, playout-build lock 409, Playwright UI flows. Assertions verified 30/30 green against a real Release-built instance; caught /artwork/* returning 400 (not the 404 a static read suggested). Docs updated same PR: docs/ci-cd.md (new job), docs/e2e-local.md (harness), docs/decisions.md (append-only). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 13:49:33 +02:00
timothyandCodex	985eed072c	docs(release): prepare v26.8.0 promotion [decisions-edit] ... refs #335 Co-Authored-By: Codex <noreply@openai.com>	2026-07-13 19:50:39 +02:00
timothyandClaude Opus 4.8	366d5d316c	feat(ci): #314 — repeatable black-box security scan (authenticated ZAP + semgrep) ... scripts/security-scan.sh: boots a THROWAWAY container from the image under test (fresh config volume; never the deployed prod/test container — the active scan attacks write endpoints), reads its machine key, and runs an authenticated OWASP ZAP api-scan that imports /openapi/v1.json (all 160 /api/v1 ops) and injects X-Api-Key on every request via a replacer rule so it reaches the [RequiresAuthentication] + RequireKeyForReads surface — then a semgrep SAST cross-check. Wrapped in `timeout` because zap-api-scan can hang in post-scan cleanup after the report is already written. docs/ci-cd.md: new 'Security scanning' section (out-of-ecosystem black-box gate, run on the docker host per-release like migration-smoke, not a per-PR CI job) + the Microsoft.OpenApi 2.7.5 pin note in dependency management. refs #314 #197 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 08:28:13 +02:00
timothyandClaude Opus 4.8	4da2b67ab2	feat(ci): #315 migration-on-prod-copy smoke for the release path ... CI's migrations job only proves a migration is well-formed against a fresh, empty DB. It never exercises the migration — or ErsatzTV's startup data steps (DatabaseMigratorService -> DbInitializer + PopulatePathHashes over the real MediaFile table) — against the accumulated prod SQLite, so a migration green on a fresh DB can still fail/corrupt on prod, found only mid-deploy. scripts/migration-smoke.sh rehearses it on a THROWAWAY copy of the latest prod backup: boots the new image against the copy, gates PASS on the "Done applying database migrations" log line (the migrator is a BackgroundService running concurrently with Kestrel, so HTTP readiness alone doesn't prove migrations finished), FAILs on early container exit / migration exception / timeout / not serving afterwards. Always operates on a copy, never the live DB; tears down its container + temp dir (incl. the container's root-owned config files) on exit. Validated live 2026-07-12: :latest vs a copy of the 283MB prod backup -> migrations applied cleanly, app booted+served, temp dir removed. Home split: this repo owns the script + docs; wiring it into the Komodo pre-deploy step is server-management#589 (cross-repo). Docs: docs/ci-cd.md (Migration integrity), docs/decisions.md (new entry, pure insertion). fixes #315 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 21:18:16 +02:00
timothyandClaude Opus 4.8	6e92a951eb	feat(process): #303 decisions.md consolidation size-floor (read-cost, non-blocking) [decisions-edit] ... Timothy's refinement: the between-releases consolidation floor triggers on the file's READ COST — its line count, i.e. the context an agent burns reading the log — not entry count. The decisions-guard CI job now emits a non-blocking ::warning:: once decisions.md exceeds 1800 lines (the point past which it no longer fits one default 2000-line agent Read). Documented in the decisions.md header, the H9 entry, and ci-cd.md (job description + release-checklist note). Touches committed H9 lines, hence [decisions-edit]. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 18:23:58 +02:00
timothyandClaude Opus 4.8	59ecafecce	docs(process): #303 fold review nits — H3 case-insensitive, granularity wording, newline note [decisions-edit] ... Adversarial review (PR #305, MERGEABLE) nits: - H3: `grep -iE` so a root `Screenshot.PNG` is caught too (was lowercase-only). - decisions-guard.sh: comment the trailing-newline assumption (dropping the final newline would make git render the next append as a last-line modify -> false-block; self-correcting via [decisions-edit], .editorconfig enforces the newline). - docs: clarify CI is PR-wide (`range`) vs Husky per-commit (`staged`) — shared detection logic, deliberately different granularity; local hook is the stricter gate. Replaces the slightly-overstated "can't drift" wording. Touches the committed H9 decisions.md entry, hence the [decisions-edit] token. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 18:18:30 +02:00
timothyandClaude Opus 4.8	997f96c1f5	docs(process): #303 append-only supersession + consolidation convention [decisions-edit] ... decisions.md header now documents the enforced append-only rule, the `[decisions-edit]` escape, mark-and-keep supersession (banner on the reversed entry + `(superseded)` TOC tag), and consolidation at each release. ci-cd.md documents H3/H9 hooks + the decisions-guard job and adds a "consolidate decisions.md" step to the release checklist. New decisions.md entry records the H9/H3 mechanization. The header edit modifies existing lines, so this commit carries the [decisions-edit] token — the guard working as designed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 18:13:13 +02:00
timothyandClaude Opus 4.8	fa2d787ac1	ci: make the MySql migration-apply resilient to concurrent-runner contention ... Root cause (diagnosed from run logs 513/515/516): the EF migration-integrity job's "MySql apply all migrations to a fresh DB" step flakes when two migration jobs land on the SAME runner host at once — each `services: mysql:8.4` container starves the other, so the 787-migration replay either exceeds MySqlConnector's 30s default command timeout ("Command Timeout expired", run 513 on ci-runner) or has its connection dropped mid-replay ("MySqlEndOfStreamException", run 516 on bumblebee-runner). It's pure infra contention: `has-pending-model-changes` (the model check) passes both providers, and the identical tree passes on a quieter host (run 515). Both runners have both passed and failed — not one bad runner. Fix (runner-agnostic, repo-owned workflow only — no runner-host change needed): - Raise `DefaultCommandTimeout` to 300s in the MySql connection string. - Wrap the apply in a 3× retry that resumes from `__EFMigrationsHistory` (EF commits each migration in its own transaction, so an interrupted one rolls back and the retry continues). A real migration failure fails on every attempt, so the retry can't mask a genuine problem. Docs: ci-cd.md migration-integrity section documents the contention + retry. Refs #13 #236 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-12 00:42:49 +02:00
timothyandClaude Opus 4.8	1b5efd7b9d	ci: prod follows :prod (remove version-pin bump-prod-compose job) ... Timothy reversed the version-pin decision: prod's media-servers compose now follows the floating :prod tag, redeployed by Komodo Global Auto Update. The bump-prod-compose job (#275) rewrote a :<version> pin, which would flip :prod -> :26.8.0 on the next release — remove it. docs/ci-cd.md reconciled to the :prod model (+ flags the open caveat: verify Global Auto Update runs the #553 pre-deploy backup, else releases deploy without a backup). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 22:20:14 +02:00
timothyandClaude Opus 4.8	0ff21d5b8e	ci: restore bump-prod-compose auto-deploy job on v* release ... The auto-pin-to-prod job designed on the unmerged `ci/auto-bump-prod-compose` branch (3d6ac883) never landed on main — so v* releases (v26.5.0, v26.6.0) did NOT auto-bump the server-management compose pin (it sat at 26.5.0). The docs (homelab-docs Docker/ErsatzTV.md, ci-cd.md) described the auto-bump as if live. Restore the job verbatim (its credentials already exist: the `ersatztv-ci-deploy` write deploy key, id 5, on server-management + the SERVERMGMT_DEPLOY_KEY secret here). On a v* tag, after the test-gated image builds, it rewrites the pinned `ersatztv:<version>` tag in docker/bumblebee/stacks/media-servers/compose.yaml and pushes to server-management `master` → the Gitea->Komodo webhook redeploys prod with a pre-deploy backup. Idempotent (no-op if already pinned). docs/ci-cd.md updated to match (release procedure + the stale ":prod pin" claim, which was actually an immutable :<version> pin since 2026-07-07). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 21:44:36 +02:00
timothyandClaude Opus 4.8	f27f458ff5	feat(web): add husky pre-commit/pre-push/commit-msg guardrails ... Installs husky git hooks (via web/'s lint-staged + npm, since the JS/TS project lives in web/ with no root package.json) to catch lint, format, type, and generated-API-drift errors locally before they reach CI. Hooks (committed at repo root under .husky/): - pre-commit: (a) lint-staged runs eslint --fix on staged web/src/**/*.{ts,tsx} + a project-wide typecheck; (b) if any *.cs are staged, dotnet format --verify-no-changes on just those files (skipped when no .cs staged, so web-only commits skip the sln load). - pre-push: CI-parity gate — cd web && check:api && lint && typecheck && build. Blocks pushing drift or a change that breaks an unstaged file. - commit-msg: requires a Co-Authored-By trailer (merge commits exempt). Wiring: web/package.json gains husky + lint-staged devDeps, a lint-staged config, and a `prepare` script (cd .. && husky) that points git's core.hooksPath at the repo-root .husky dir on npm install. A fresh `web/` npm install installs all four hooks automatically. Monorepo/worktree gotchas handled: - husky init hard-checks for .git in cwd, so `prepare` cd's to the repo root before invoking husky (npm keeps web/node_modules/.bin on PATH). - git exports GIT_DIR while running hooks; in a worktree/subdir that made pre-push's `git diff` (check:api) mislocate the working tree and pass silently on drift — pre-push now unsets GIT_DIR/GIT_WORK_TREE/GIT_INDEX_FILE. docs/ci-cd.md: new "Pre-commit hooks (web/)" section covering all four. Verified: eslint error blocks commit; clean commit passes; bad-format .cs blocks (dotnet format ~6-7s scoped), good .cs passes; check:api drift and a lint error each block `git push --dry-run`, clean state passes; missing Co-Authored-By blocks commit-msg, present passes; non-web/.cs commits skip lint/format. npm run lint clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-11 19:31:22 +02:00
timothyandClaude Fable 5	1bef9c9076	ci: small-runner lane + per-ref concurrency (queue starvation fix) ... - build & docs-reminder jobs -> runs-on: small (dedicated small-jobs runner, server-management#574). Gitea dispatches a job as a runner task even when its 'if' skips it; the PR-run skip of 'Build & push image' waited up to 31 min for an ubuntu-latest slot, stalling every PR run. - concurrency scoped per event+ref with cancel-in-progress for PRs: runs parallelize across PRs, superseded syncs auto-cancel. Previously one global group serialized ALL runs (single-runner relic). Main/tag builds still serialize within their ref; don't push main + v* tag simultaneously (shared :buildcache / smoke container) — tag after main is green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-11 11:40:30 +02:00
timothyandClaude Opus 4.8	6bdb7dae1c	docs+ci: harden the docs-first rule + add a non-blocking parity-doc reminder ... CLAUDE.md Conventions: turn "read docs before exploring" into a hard rule with red-flag framing (do NOT reverse-engineer conventions from source; applies to subagents too) and a "which doc to update in the same PR" table. Add a lightweight, PR-only, NON-BLOCKING `docs-reminder` CI job that warns when a screen/route change skips docs/blazor-route-parity.md. No dotnet/node in that job (no actions/cache), so it can't hit the VM-127 cache-save issues (server-management#570). Documented in docs/ci-cd.md. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-08 22:17:25 +02:00
timothy	35e5799cd6	docs(ci-cd): runner relocated off bumblebee to ci-runner VM 127 (server-management#570) ... Update stale jazz/bumblebee runner references: concurrency note, amd64 host note, EF-migration mysql-service network (now per-job, not downloadswarm), and registry insecure-registry host.	2026-07-08 19:09:49 +00:00
timothyandClaude Opus 4.8	e68aa5834c	ci: speed up build pipeline (NuGet cache, shallow checkout, jar layer reorder) ... Three CI wins from ersatztv#190, all config-only: - Cache ~/.nuget/packages via actions/cache@v4 in both the `test` and `migrations` jobs, keyed on Directory.Packages.props + global.json, so dotnet restore no longer starts from scratch every run. - Shallow-checkout the `test` job (fetch-depth: 1) since it never runs git describe/log; only `build` needs full history for versioning. The `migrations` job's checkout was already effectively shallow (default fetch-depth 1), documented explicitly. - Reorder the Dockerfile so the openapi-generator jar wget happens before the openapi spec COPY, decoupling the ~30MB download layer from spec changes (e.g. v1.json) that previously busted it on every API PR. Documented all three in docs/ci-cd.md alongside the existing job/Dockerfile notes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-08 19:37:31 +02:00
timothy	e170b2dc3c	fix(ffmpeg): align transcode pipelines with ffmpeg 8 ... refs #9	2026-07-01 19:37:51 +02:00
timothyandClaude Opus 4.8	2edf3dab49	ci: assert key IPTV endpoints in the container smoke test (#16) ... Extend the image smoke test from "serves HTTP" to a real E2E: after HTTP readiness, assert the Jellyfin-facing surfaces on the freshly built image — /iptv/channels.m3u returns 2xx containing #EXTM3U, and /iptv/xmltv.xml returns 2xx containing a <tv root. xmltv.xml needs channels.xml (the scheduler writes it a few seconds after boot), so each endpoint is polled with a deadline; container logs are dumped on failure. Catches routing / base-URL (#1) / migration regressions that leave the app "up" but serving broken playlists/guides. Validated the exact checks against the real :latest image on a fresh container (both 200 with the expected shape) before committing. Refs #16 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-27 11:22:47 +02:00
timothyandClaude Opus 4.8	307da32f34	ci: EF migration integrity checks for SQLite + MySql (#13) ... New `migrations` job in docker-build.yml runs on every push/PR and, per provider: - `dotnet ef migrations has-pending-model-changes` — fails on model drift (an entity changed without a matching migration). - `dotnet ef database update` against a fresh empty DB — applies all migrations, catching broken/un-orderable ones. SQLite (the prod provider) uses a throwaway file; MySql uses ServerVersion.AutoDetect (connects at config time), so the job runs a `services: mysql:8.4` container (the act_runner uses Docker execution on network downloadswarm, so the service is reachable as `mysql:3306`). Independent gate for now (not a `needs:` of the image build) so the MySql-service dependency can't block image builds until proven stable. Validated both providers locally against real DBs: SQLite 787 migrations -> 139 tables; MySql 8.4 305 migrations -> 137 tables; both model-drift checks clean. Docs: ci-cd.md "Migration integrity" (dual-provider discipline, EF CLI pattern, the non-transactional caveat) + CLAUDE.md convention. Refs #13 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-27 10:58:41 +02:00
3 people	f2d0a36ed6	build: adopt static-analysis packs at suggestion (#15, increment 1) ... Add Roslynator, SonarAnalyzer.CSharp, Meziantou.Analyzer, and AsyncFixer as central analyzer references (Directory.Build.targets, CPM-versioned, guarded on ManagePackageVersionsCentrally so the gitignored .mcp tool isn't affected). .editorconfig defaults dotnet_analyzer_diagnostic.severity to `suggestion` so the packs surface findings without failing the TreatWarningsAsErrors (TWAE) build; rules are promoted to warning/error incrementally (promotion = enforcement via the existing TWAE build, so no separate lint step is needed). StyleCop.Analyzers is intentionally excluded: its latest stable (1.1.118) crashes (AD0001) on C# records and overlaps the existing .editorconfig/Roslynator. Blazor .razor: editorconfig severity overrides don't reach analyzer diagnostics in Razor @code (source-generator limitation; dotnet format can't fix them either), so the currently-firing SonarAnalyzer rules are temporarily NoWarn-ed in ErsatzTV.csproj and burned down rule-by-rule in #25. The same rules run at suggestion on .cs. Formatting normalization (mixed UTF-8 BOM + whitespace) is deferred to its own PR. Full-solution Release build green (0 errors, 0 warnings). Refs #15 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-27 07:37:15 +00:00
timothyandClaude Opus 4.8	f1ff39954f	docs(renovate): Dockerfile manager now enabled (HTTP registry) [skip ci] ... The previously-deferred dockerfile manager is live: it manages docker/Dockerfile (mcr dotnet bases + internal ersatztv-ffmpeg) and reads the HTTP-only Gitea registry via a RENOVATE_HOST_RULES host rule (insecureRegistry + read creds) set in the workflow env. Vestigial arm/ffmpeg-tests Dockerfiles excluded; compose manager unused (build-only). refs server-management#484 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-27 02:22:08 +02:00
timothyandClaude Opus 4.8	74815da024	docs: NCalcSync/SQLitePCLRaw advisories resolved (#8) [skip ci] ... Update ci-cd.md: the scheduled vuln scan is green now that #8 cleared the advisories (red = a new one); note the NU1901-1903 demotion is kept by design (criticals still block; lower severities surface via the scan + Renovate). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-27 02:17:55 +02:00
timothyandClaude Opus 4.8	97bf50cb5b	docs(renovate): document live Renovate setup [skip ci] ... Renovate is now live (PR #18/#19): self-hosted weekly Gitea Actions job that opens dependency-update + OSV vuln-fix PRs and a Dependency Dashboard, with patch-level auto-merge scoped to test/dev-only packages. Document it under docs/ci-cd.md → Dependency management, plus a CLAUDE.md conventions pointer. refs server-management#484 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-27 01:57:11 +02:00
timothyandClaude Opus 4.8	d9cdff8154	docs: record Central Package Management + scheduled vuln scan (#14) [skip ci] ... - ci-cd.md: new "Dependency management" section (CPM, NuGet audit, scheduled dependency-scan.yml); Dockerfile notes now list Directory.Packages.props and why it's required before restore. - CLAUDE.md: dependency convention (edit central Directory.Packages.props, never re-add Version=); correct the test framework note (NUnit, not xUnit). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-27 01:33:44 +02:00
timothyandClaude Opus 4.8	0e5e6ebc72	docs: note Gitea drops runs on rapid back-to-back pushes [skip ci] ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-27 00:44:23 +02:00
timothyandClaude Opus 4.8	c7aad4689e	docs: enshrine the fork versioning scheme ... Document upstream's vYY.<release-seq>.<patch> scheme (year, sequential release-in-year, patch) in docs/ci-cd.md + CLAUDE.md so we follow it going forward: <release-seq> is NOT the calendar month (v25.2.0 shipped in June, v26.3.0 in Feb), it's a per-year counter that resets each January. v26.3.1 = our infra-only rebuild of upstream 26.3.0; v26.4.0 reserved for the first release with app changes. Also notes the [skip ci]-on-a-tagged-commit gotcha. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-27 00:29:13 +02:00