test: the updater digest check runs where only a later .NET SDK is installed #2294

Merged
mooki000 merged 1 commit from test/updater-digest-net8 into main 2026-11-11 20:31:21 +00:00
mooki000 commented 2026-11-11 13:53:25 +00:00 (Migrated from github.com)

tests/test_updater_asset_digest.py fails on a PC whose only .NET SDK is newer than 8 (here Arch's .NET SDK
10.0.113): its fixture targets net8.0 with NuGet's sources cleared, and that SDK has no 8.0 reference pack to build
against.

Part of #2334.

Fixture.csproj : error NU1100: Unable to resolve 'Microsoft.NETCore.App.Ref (= 8.0.32)' for 'net8.0'.

.NET 8's support ended on 2026-11-10, so more machines, and in time CI images, will have only later SDKs.

What changed

  • tests/test_updater_asset_digest.py still builds the real builder/HookshotBuilder/Updater.cs for net8.0, the
    builder's framework, wherever the SDK can restore it. It restores first; when that fails with NU1100 (the
    reference pack is not installed, and nothing is fetched since the sources are cleared), it builds for the SDK's own
    framework (net<major of dotnet --version>.0) and says so in one line:

    this .NET SDK (10.0.113) has no .NET 8 reference pack: the updater is built for net10.0, not the builder's net8.0
    

    Any other restore failure still fails the check with dotnet's output.

  • The message when dotnet is missing says a .NET SDK is needed, since 8 is no longer the only one that runs it.

Why not skip instead: a skip passes silently (run_all.py has no way for a check to report a skip at run time), and
the cases do not depend on the framework (the HTTP, process and file boundaries are the fixture's fakes). The builder
itself still targets net8.0; CI's Windows job installs .NET 8.0.x (actions/setup-dotnet), and the ubuntu-24.04 image
lists .NET SDKs 8.0, 9.0 and 10.0 side by side (runner-images readme, image 20261101), so CI should keep building for
net8.0; not checked on CI itself.

How it was tested

Linux (Arch, .NET SDK 10.0.113 only):

  • Main: fails with NU1100 as above.
  • With the change: the line above, then Updater digest cases: 20 passed, 0 failed. (6.6 s in run_all.py).
  • The same build with a copy of Updater.cs whose SHA-256 comparison was made to accept anything: 5 cases fail
    (setup-corrupt-no-use, folder-setup-corrupt-no-use, zip-corrupt-no-extract, api-corrupt-terminal,
    chunked-corrupt), so the check still catches a broken updater when built for net10.0.
  • python -I -B tests/run_all.py on main 49f75dc8 with this change (2026-11-11, load about 100 to 135): 363 passed, 1
    failed, 10 skipped; tests/test_updater_asset_digest.py passes. The one failure, tests/test_wayland_libdecor_hint.py,
    fails on main as well on this machine (Clang 23; fixed by #2290).

Not tested

  • A machine with the .NET 8 SDK (the net8.0 path is the one main had; CI runs it).
  • Windows.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 [email protected]

`tests/test_updater_asset_digest.py` fails on a PC whose only .NET SDK is newer than 8 (here Arch's .NET SDK 10.0.113): its fixture targets net8.0 with NuGet's sources cleared, and that SDK has no 8.0 reference pack to build against. Part of #2334. ``` Fixture.csproj : error NU1100: Unable to resolve 'Microsoft.NETCore.App.Ref (= 8.0.32)' for 'net8.0'. ``` .NET 8's support ended on 2026-11-10, so more machines, and in time CI images, will have only later SDKs. ## What changed - `tests/test_updater_asset_digest.py` still builds the real `builder/HookshotBuilder/Updater.cs` for net8.0, the builder's framework, wherever the SDK can restore it. It restores first; when that fails with NU1100 (the reference pack is not installed, and nothing is fetched since the sources are cleared), it builds for the SDK's own framework (`net<major of dotnet --version>.0`) and says so in one line: ``` this .NET SDK (10.0.113) has no .NET 8 reference pack: the updater is built for net10.0, not the builder's net8.0 ``` Any other restore failure still fails the check with dotnet's output. - The message when `dotnet` is missing says a .NET SDK is needed, since 8 is no longer the only one that runs it. Why not skip instead: a skip passes silently (`run_all.py` has no way for a check to report a skip at run time), and the cases do not depend on the framework (the HTTP, process and file boundaries are the fixture's fakes). The builder itself still targets net8.0; CI's Windows job installs .NET 8.0.x (`actions/setup-dotnet`), and the ubuntu-24.04 image lists .NET SDKs 8.0, 9.0 and 10.0 side by side (runner-images readme, image 20261101), so CI should keep building for net8.0; not checked on CI itself. ## How it was tested Linux (Arch, .NET SDK 10.0.113 only): - Main: fails with NU1100 as above. - With the change: the line above, then `Updater digest cases: 20 passed, 0 failed.` (6.6 s in `run_all.py`). - The same build with a copy of `Updater.cs` whose SHA-256 comparison was made to accept anything: 5 cases fail (`setup-corrupt-no-use`, `folder-setup-corrupt-no-use`, `zip-corrupt-no-extract`, `api-corrupt-terminal`, `chunked-corrupt`), so the check still catches a broken updater when built for net10.0. - `python -I -B tests/run_all.py` on main 49f75dc8 with this change (2026-11-11, load about 100 to 135): 363 passed, 1 failed, 10 skipped; `tests/test_updater_asset_digest.py` passes. The one failure, `tests/test_wayland_libdecor_hint.py`, fails on main as well on this machine (Clang 23; fixed by #2290). ## Not tested - A machine with the .NET 8 SDK (the net8.0 path is the one main had; CI runs it). - Windows. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <[email protected]>
mooki000 commented 2026-11-11 17:08:20 +00:00 (Migrated from github.com)

Rebased onto main b29967bf so the workflows run here: they had waited for an approval on the old head, and main's game-free tests are green again since #2380. The patch is unchanged (git range-diff: the commit is equal), and its test passes on the new base.

Rebased onto main `b29967bf` so the workflows run here: they had waited for an approval on the old head, and main's game-free tests are green again since #2380. The patch is unchanged (`git range-diff`: the commit is equal), and its test passes on the new base.
Joey-Magnus (Migrated from github.com) approved these changes 2026-11-11 20:07:56 +00:00
Joey-Magnus (Migrated from github.com) left a comment

This looks right to me. The fallback is narrow: only a failed restore that mentions NU1100 switches the framework. Since the fixture has no package references and the NuGet sources are cleared, that can only mean the net8.0 reference pack is missing. Any other restore failure still fails the check with dotnet's output. The cases themselves don't depend on the framework, and your mutation run (5 corrupt-digest cases failing under net10.0) shows the check keeps its teeth there.

CI: the updater digest check passed on both the ubuntu-24.04 and windows-2022 jobs, built for net8.0. The two failing jobs are unrelated. Python source checks (windows-2022, part 1/2) failed in test_native_astc_texture_count.py (the scanf deprecation, fixed on main by #2397), and appimage failed on a Launchpad connection timeout during add-apt-repository. A rebase or re-run should turn both green.

One suggestion, not blocking:

  • minor tests/test_updater_asset_digest.py:45: on CI the fallback would hide exactly the regression the builder cares about. If a runner image ever drops the .NET 8 pack, or Updater.cs starts using an API newer than .NET 8, the check would quietly build for net10.0 and pass, while the real builder no longer compiles. CI only prints one line in that case. Consider failing instead of falling back when GITHUB_ACTIONS (or CI) is set, or when run_all.py runs with --strict, so net8.0 stays enforced where it is supposed to be available, while local machines with only a newer SDK keep the fallback.
This looks right to me. The fallback is narrow: only a failed restore that mentions NU1100 switches the framework. Since the fixture has no package references and the NuGet sources are cleared, that can only mean the net8.0 reference pack is missing. Any other restore failure still fails the check with dotnet's output. The cases themselves don't depend on the framework, and your mutation run (5 corrupt-digest cases failing under net10.0) shows the check keeps its teeth there. CI: the updater digest check passed on both the ubuntu-24.04 and windows-2022 jobs, built for net8.0. The two failing jobs are unrelated. `Python source checks (windows-2022, part 1/2)` failed in `test_native_astc_texture_count.py` (the `scanf` deprecation, fixed on main by #2397), and `appimage` failed on a Launchpad connection timeout during `add-apt-repository`. A rebase or re-run should turn both green. One suggestion, not blocking: - **minor** `tests/test_updater_asset_digest.py:45`: on CI the fallback would hide exactly the regression the builder cares about. If a runner image ever drops the .NET 8 pack, or `Updater.cs` starts using an API newer than .NET 8, the check would quietly build for net10.0 and pass, while the real builder no longer compiles. CI only prints one line in that case. Consider failing instead of falling back when `GITHUB_ACTIONS` (or `CI`) is set, or when `run_all.py` runs with `--strict`, so net8.0 stays enforced where it is supposed to be available, while local machines with only a newer SDK keep the fallback.
mooki000 commented 2026-11-11 22:46:37 +00:00 (Migrated from github.com)

@Joey-Magnus thanks for the review. Your suggestion is in #2543: on a GitHub runner a failed net8.0 restore now fails the check instead of falling back to a later framework. On a PC the fallback is unchanged.

@Joey-Magnus thanks for the review. Your suggestion is in #2543: on a GitHub runner a failed `net8.0` restore now fails the check instead of falling back to a later framework. On a PC the fallback is unchanged.
Commenting is not possible because the repository is archived.
No description provided.