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.
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.
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 main2026-07-30 23:31:33 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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.Also refreshes the #8 security-pin comment, which named
3.0.3explicitly. 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 satisfiesMicrosoft.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:
#679EF migration —SQLite Error 13: 'database or disk is full',ENOSPC: no space left on device, mkdir …#679E2E —ErsatzTV requires at least 128 MB of free space at /tmp/…#679script tests /#680docs reminder — log file missing entirely (killed-job signal); the docs job ran 10m21s against a ~20s norm#681EF migration — died in tar cache-restore withNo space left on device, before either the SQLite or MySQL half ran, so the native-bundle bump was never actually exercised thereThe 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-existingCS*nullability in test projects.dotnet ef database updateapplied 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 runningOn 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:.editorconfigsetsdotnet_analyzer_diagnostic.severity = suggestionrepo-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.propssetsTreatWarningsAsErrors=truein six main projects, but noMA0*rule is individually promoted abovesuggestionanywhere (root.editorconfig, per-project.editorconfigs, andeng/analyzers/sdk-all-suggestion.globalconfig, which is CA-only). OnlyS3981is promoted, and that is a Sonar rule. A new Meziantou rule therefore lands atsuggestionand 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 statuscontext 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/h10invariant 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
3.0.3reference in the security-pin comment correctedBuild & test (.NET)andEF migration integrity (SQLite + MySql)both green onfbbdaeca3, which is what review conditioned its verdict onPost-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.
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.
Review-verdict: MERGEABLE @
fbbdaecCold 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.