schmidt.florian
cf7e0396f0
ci / build-test (push) Successful in 1m13s
The instance had no idea what version it was: VERSION drives tagging and the image publish, but was never stamped into the assemblies, so a running build reported 1.0.0 forever. Directory.Build.props now stamps it into every project. The dashboard compares that against the newest tag in the source repository and shows a banner when behind. A plain GET of a public tag list -- nothing about the instance is sent -- cached six hours, failing quiet. Two things it deliberately does not do. It never blocks a render: the banner paints from the cached answer and refreshes after first render, so a cold start or an unreachable repository costs nothing rather than holding the dashboard open for an HTTP timeout. And it never guesses: an unknown version on either side shows no banner at all, because a banner that cannot clear trains people to ignore the next real one. Version comparison is numeric on exactly three components, not System.Version and not string order. Tags are written vX.Y.Z, the assembly reports X.Y.Z with a +commithash suffix, and "0.10.0" sorts below "0.9.0" as a string -- each of those is a way the banner sticks or never appears. Prerelease suffixes compare equal to their release so an rc tag does not nag. Gitea does not promise semver ordering, so the highest tag wins rather than the first. The command shown depends on the install: the LXC has `update`, a container is replaced by pulling an image, and telling container users to run `update` sends them after a command that does not exist. No update *button*. The UI has no authentication and the LXC runs the app as root, and `update` builds whatever is on master, so a click would be an unauthenticated path to arbitrary code execution for anything on the LAN. The README now states the no-auth position plainly rather than leaving it implied. Tests cover the parse and ordering cases that would strand a banner, the Gitea payload shape captured from the live API, unreachable and garbage responses, and that the VERSION file actually reaches the assembly -- read from MeterVault's own assembly rather than GetEntryAssembly(), which under `dotnet test` is the test host and reported a confident wrong answer. The suite makes no outbound request: the app factory disables the check. Claude-Session: https://claude.ai/code/session_01V6joyergfvVLFEizH1hJLd
29 lines
1.2 KiB
C#
29 lines
1.2 KiB
C#
using Microsoft.AspNetCore.Hosting;
|
|
using Microsoft.AspNetCore.Mvc.Testing;
|
|
|
|
namespace MeterVault.Integration.Tests;
|
|
|
|
/// <summary>
|
|
/// Boots the real ASP.NET Core app in-memory against the shared Timescale container.
|
|
/// Migrations are already applied by <see cref="TimescaleFixture"/>, so startup migration is off.
|
|
/// </summary>
|
|
public sealed class MeterVaultAppFactory(string connectionString, bool configureApiKey = true) : WebApplicationFactory<Program>
|
|
{
|
|
public const string ApiKey = "test-api-key";
|
|
|
|
protected override void ConfigureWebHost(IWebHostBuilder builder)
|
|
{
|
|
builder.UseEnvironment("Testing");
|
|
builder.UseSetting("ConnectionStrings:Default", connectionString);
|
|
builder.UseSetting("MeterVault:RunMigrationsAtStartup", "false");
|
|
builder.UseSetting("MeterVault:EnableLiveIngestion", "false");
|
|
// No outbound calls from tests: the update check would otherwise hit the real Gitea on every
|
|
// page render, making the suite slow and dependent on that host being up.
|
|
builder.UseSetting("MeterVault:UpdateCheckEnabled", "false");
|
|
if (configureApiKey)
|
|
{
|
|
builder.UseSetting("MeterVault:ApiKeys:0", ApiKey);
|
|
}
|
|
}
|
|
}
|