chore(deps): batch three Renovate patch bumps (supersedes #679, #680, #681) #714

Merged
timothy merged 1 commits from chore/renovate-batch-2026-07-30 into main 2026-07-30 23:31:33 +02:00
Owner

Consolidates the three open Renovate PRs into one change so they land on a single CI pipeline instead of three. They all edit Directory.Packages.props, so merging them individually would force a rebase and a full re-run for each remaining PR.

Package From To
CliWrap 3.10.2 3.10.3
Meziantou.Analyzer 3.0.115 3.0.129
SQLitePCLRaw.bundle_e_sqlite3 3.0.3 3.0.4

Also refreshes the #8 security-pin comment, which named 3.0.3 explicitly. Renovate only rewrites the version attribute, so its own PR would have left that comment contradicting the line directly beneath it. The pin's intent is unchanged: stay on the 3.x line that ships the patched native SQLite (GHSA-2m69-gcr7-jv3q), and 3.0.4 still satisfies Microsoft.Data.Sqlite's >= 2.1.10.

Why the originals were red

All three failed on 2026-07-27, but none of the failures reached any code. The runner host had exhausted its disk at ~03:20 UTC:

  • #679 EF migration — SQLite Error 13: 'database or disk is full', ENOSPC: no space left on device, mkdir …
  • #679 E2E — ErsatzTV requires at least 128 MB of free space at /tmp/…
  • #679 script tests / #680 docs reminder — log file missing entirely (killed-job signal); the docs job ran 10m21s against a ~20s norm
  • #681 EF migration — died in tar cache-restore with No space left on device, before either the SQLite or MySQL half ran, so the native-bundle bump was never actually exercised there

The host has since recovered (38% root, 10% docker) and the operator reports it fixed.

Verification

Local, on this combined change:

  • dotnet build -c Release → 0 errors; 48 warnings, all pre-existing CS* nullability in test projects.
  • Full test suite → 4440 passed, 0 failed across all 7 test projects.
  • SQLite model drift clean + dotnet ef database update applied every migration to a fresh DB → Done.

On the real runners (head fbbdaeca3), 12 checks green, notably:

  • Build & test (.NET) → success in 22m47s (a genuine full run, not a docs-only fast path)
  • EF migration integrity (SQLite + MySql) → success in 20m9s — the exact job that was red on #681, this time with both the SQLite and MySQL halves actually running

On the analyzer bump specifically

An earlier draft of this description claimed that observing zero MA*/S*/CA* diagnostics proved the Meziantou 3.0.115 → 3.0.129 jump introduces no new rules that bite. Cold review correctly flagged that as overstated: .editorconfig sets dotnet_analyzer_diagnostic.severity = suggestion repo-wide as a bulk catch-all, so a newly-shipped rule would produce zero build diagnostics whether or not it fired. The observation was therefore not evidence of what it was claimed to show.

The conclusion still holds, for a different reason: Directory.Build.props sets TreatWarningsAsErrors=true in six main projects, but no MA0* rule is individually promoted above suggestion anywhere (root .editorconfig, per-project .editorconfigs, and eng/analyzers/sdk-all-suggestion.globalconfig, which is CA-only). Only S3981 is promoted, and that is a Sonar rule. A new Meziantou rule therefore lands at suggestion and cannot fail the build. The safety comes from the severity posture, not from the zero-diagnostic observation.

A status race worth recording

The Review verdict / Set review-verdict status context went red on this PR without anything being wrong with it. Two runs fired on the same sha: run 1757 (started 20:59:08Z) and run 1758 (started 21:05:38Z). 1758 succeeded in 6s and posted green; 1757 was then killed and finished at 21:10:55Z, five minutes later, posting red over the newer green. Its job log is absent (OpenLogs: … file does not exist), which is the killed-job tell.

The review-verdict/h10 invariant is carefully sha-bound so a stale verdict cannot survive a new head. The workflow's own job context has no equivalent protection — last writer wins, and "last" means last to finish, not last to start. So a killed long run can revert a passing short one on an identical sha. Not a defect in this change; noted because the merge gate reads the combined status, so this class of race can block a merge for no real reason.

Done-when

  • All three bumps applied and building clean
  • Full test suite green locally
  • SQLite migration integrity verified locally, then confirmed green on the real runners
  • Stale 3.0.3 reference in the security-pin comment corrected
  • Adversarial review passed (cold, worktree-isolated; MERGEABLE, no Blocker/High)
  • CI green — Build & test (.NET) and EF migration integrity (SQLite + MySql) both green on fbbdaeca3, which is what review conditioned its verdict on

Post-merge follow-up

Deliberately not a Done-when box: closing the superseded PRs before this one lands would leave three PRs closed with nothing merged.

  • Close #679, #680, #681 as superseded once this merges.
  • Next Renovate run: SQLitePCLRaw 3.0.5 and Meziantou.Analyzer 3.0.137 have already shipped upstream, so fresh PRs for those are expected.

No docs update required: this changes no convention, route, endpoint, or decision — it is a version-only dependency bump plus a comment correction in the same file.

Consolidates the three open Renovate PRs into one change so they land on a single CI pipeline instead of three. They all edit `Directory.Packages.props`, so merging them individually would force a rebase and a full re-run for each remaining PR. | Package | From | To | |---|---|---| | CliWrap | 3.10.2 | 3.10.3 | | Meziantou.Analyzer | 3.0.115 | 3.0.129 | | SQLitePCLRaw.bundle_e_sqlite3 | 3.0.3 | 3.0.4 | Also refreshes the #8 security-pin comment, which named `3.0.3` explicitly. Renovate only rewrites the version attribute, so its own PR would have left that comment contradicting the line directly beneath it. The pin's intent is unchanged: stay on the 3.x line that ships the patched native SQLite (GHSA-2m69-gcr7-jv3q), and 3.0.4 still satisfies `Microsoft.Data.Sqlite`'s `>= 2.1.10`. ## Why the originals were red All three failed on 2026-07-27, but **none of the failures reached any code**. The runner host had exhausted its disk at ~03:20 UTC: - `#679` EF migration — `SQLite Error 13: 'database or disk is full'`, `ENOSPC: no space left on device, mkdir …` - `#679` E2E — `ErsatzTV requires at least 128 MB of free space at /tmp/…` - `#679` script tests / `#680` docs reminder — log file missing entirely (killed-job signal); the docs job ran 10m21s against a ~20s norm - `#681` EF migration — died in tar cache-restore with `No space left on device`, **before either the SQLite or MySQL half ran**, so the native-bundle bump was never actually exercised there The host has since recovered (38% root, 10% docker) and the operator reports it fixed. ## Verification Local, on this combined change: - `dotnet build -c Release` → **0 errors**; 48 warnings, all pre-existing `CS*` nullability in test projects. - Full test suite → **4440 passed, 0 failed** across all 7 test projects. - SQLite model drift clean + `dotnet ef database update` applied every migration to a fresh DB → `Done.` On the real runners (head `fbbdaeca3`), 12 checks green, notably: - `Build & test (.NET)` → success in **22m47s** (a genuine full run, not a docs-only fast path) - `EF migration integrity (SQLite + MySql)` → success in **20m9s** — the exact job that was red on #681, this time with both the SQLite and MySQL halves actually running ### On the analyzer bump specifically An earlier draft of this description claimed that observing zero `MA*`/`S*`/`CA*` diagnostics proved the Meziantou 3.0.115 → 3.0.129 jump introduces no new rules that bite. Cold review correctly flagged that as overstated: `.editorconfig` sets `dotnet_analyzer_diagnostic.severity = suggestion` repo-wide as a bulk catch-all, so a newly-shipped rule would produce zero build diagnostics **whether or not it fired**. The observation was therefore not evidence of what it was claimed to show. The conclusion still holds, for a different reason: `Directory.Build.props` sets `TreatWarningsAsErrors=true` in six main projects, but no `MA0*` rule is individually promoted above `suggestion` anywhere (root `.editorconfig`, per-project `.editorconfig`s, and `eng/analyzers/sdk-all-suggestion.globalconfig`, which is CA-only). Only `S3981` is promoted, and that is a Sonar rule. A new Meziantou rule therefore lands at `suggestion` and cannot fail the build. The safety comes from the severity posture, not from the zero-diagnostic observation. ### A status race worth recording The `Review verdict / Set review-verdict status` context went red on this PR without anything being wrong with it. Two runs fired on the same sha: run 1757 (started 20:59:08Z) and run 1758 (started 21:05:38Z). 1758 succeeded in 6s and posted green; 1757 was then killed and finished at 21:10:55Z, five minutes *later*, posting red over the newer green. Its job log is absent (`OpenLogs: … file does not exist`), which is the killed-job tell. The `review-verdict/h10` invariant is carefully sha-bound so a stale verdict cannot survive a new head. The workflow's **own** job context has no equivalent protection — last writer wins, and "last" means last to *finish*, not last to start. So a killed long run can revert a passing short one on an identical sha. Not a defect in this change; noted because the merge gate reads the combined status, so this class of race can block a merge for no real reason. ## Done-when - [x] All three bumps applied and building clean - [x] Full test suite green locally - [x] SQLite migration integrity verified locally, then confirmed green on the real runners - [x] Stale `3.0.3` reference in the security-pin comment corrected - [x] Adversarial review passed (cold, worktree-isolated; MERGEABLE, no Blocker/High) - [x] CI green — `Build & test (.NET)` and `EF migration integrity (SQLite + MySql)` both green on `fbbdaeca3`, which is what review conditioned its verdict on ## Post-merge follow-up Deliberately **not** a Done-when box: closing the superseded PRs before this one lands would leave three PRs closed with nothing merged. - Close #679, #680, #681 as superseded once this merges. - Next Renovate run: SQLitePCLRaw 3.0.5 and Meziantou.Analyzer 3.0.137 have already shipped upstream, so fresh PRs for those are expected. No docs update required: this changes no convention, route, endpoint, or decision — it is a version-only dependency bump plus a comment correction in the same file.
timothy added 1 commit 2026-07-30 22:58:32 +02:00
chore(deps): batch three Renovate patch bumps
PR Gates / Docs update reminder (pull_request) Successful in 22s
PR Gates / CI image pin matches docker/ci (pull_request) Successful in 25s
PR Gates / decisions lifecycle (pull_request) Successful in 32s
Build ErsatzTV Image / API docs in sync (OpenAPI + endpoint index) (pull_request) Successful in 58s
Build ErsatzTV Image / Formatting (changed .cs conform to .editorconfig) (pull_request) Successful in 57s
PR Gates / Script tests (pytest) (pull_request) Successful in 1m8s
Build ErsatzTV Image / Functional E2E (curl + UI contracts) (pull_request) Successful in 6m23s
Build ErsatzTV Image / EF migration integrity (SQLite + MySql) (pull_request) Successful in 20m9s
Build ErsatzTV Image / Build & test (.NET) (pull_request) Successful in 22m47s
Build ErsatzTV Image / Build & push image (amd64) (pull_request) Has been skipped
review-verdict/h10 Review-verdict: MERGEABLE @ fbbdaec (base: main)
Review verdict / Set review-verdict status (pull_request_target) Successful in 5s
fbbdaeca3c
Consolidates the three open Renovate PRs into one change so they land on a
single CI pipeline instead of three. They all edit Directory.Packages.props,
so merging them individually would force a rebase + full re-run for each
remaining PR.

  CliWrap                        3.10.2  -> 3.10.3
  Meziantou.Analyzer             3.0.115 -> 3.0.129
  SQLitePCLRaw.bundle_e_sqlite3  3.0.3   -> 3.0.4

Also refreshes the #8 security-pin comment, which named 3.0.3 explicitly.
Renovate only rewrites the version attribute, so its own PR would have left
that comment contradicting the line directly beneath it. The pin's intent is
unchanged: stay on the 3.x line that ships the patched native SQLite
(GHSA-2m69-gcr7-jv3q), and 3.0.4 still satisfies Microsoft.Data.Sqlite's
`>= 2.1.10`.

All three original PRs went red on 2026-07-27, but none of the failures
reached any code. The runner host had exhausted its disk at ~03:20 UTC:
tar cache-restore failing with "No space left on device", SQLite Error 13
"database or disk is full", and ErsatzTV refusing to boot for want of 128 MB
of free space. #681's migration job in particular died during cache restore,
before either the SQLite or MySQL half ran, so the native-bundle bump was
never actually exercised there.

Verified locally on this combined change:
  - dotnet build -c Release: 0 errors; zero MA/S/CA analyzer diagnostics, so
    the Meziantou 3.0.115 -> 3.0.129 jump introduces no new rules that bite
  - full test suite: 4440 passed, 0 failed across all 7 test projects
  - SQLite model drift clean + all migrations applied to a fresh DB, which is
    the exact job that was red on #681

Supersedes #679, #680, #681.
Author
Owner

Review-verdict: MERGEABLE @ fbbdaec

Cold worktree-isolated adversarial review, no Blocker/High. Verified: three target versions match the Renovate branches exactly; CPM intact (no Version= on any of the six PackageReference sites); no packages.lock.json to go stale; no stale version assertions elsewhere in the repo; #8 security-pin intent preserved and its comment now self-consistent. Review made the verdict conditional on Build and test plus EF migration integrity going green on the real runners rather than on local claims; both are now green on this sha (22m47s and 20m9s), the latter being the exact job that was red on superseded PR 681.

Review-verdict: MERGEABLE @ fbbdaec Cold worktree-isolated adversarial review, no Blocker/High. Verified: three target versions match the Renovate branches exactly; CPM intact (no Version= on any of the six PackageReference sites); no packages.lock.json to go stale; no stale version assertions elsewhere in the repo; #8 security-pin intent preserved and its comment now self-consistent. Review made the verdict conditional on Build and test plus EF migration integrity going green on the real runners rather than on local claims; both are now green on this sha (22m47s and 20m9s), the latter being the exact job that was red on superseded PR 681.
timothy merged commit 9928be805f into main 2026-07-30 23:31:33 +02:00
timothy deleted branch chore/renovate-batch-2026-07-30 2026-07-30 23:31:33 +02:00
Sign in to join this conversation.