Files
vfxreview/prisma/migrations/20260813010000_tool_versions/migration.sql
T
twotalesanimation a4f8226f3f feat(pipeline): report deployed tool versions from the tools themselves
"What is running where" was answerable only by asking someone. Each tool
now reports its own version on startup into a ToolVersion registry, shown
on Pipeline → Machines.

The worker's version moves out of config.json and into the assembly:
a hand-maintained string on each machine is exactly the thing that goes
stale, and a machine reporting a version it is not running is worse than
no version at all. publish.ps1 stamps the git SHA via SourceRevisionId,
so a deployed exe traces back to a commit (1.1.0+feb1c7b).

The panel gains PANEL_VERSION, shown in its title and every diagnostics
report, and pings on load.

Staleness is derived rather than declared: the newest version seen for a
tool is the benchmark, so updating one machine is what flags the rest.
There is no expected-version list to keep in sync — which would have been
one more thing to forget.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 15:13:44 +02:00

24 lines
704 B
SQL

-- Deployed tool versions, reported by the tools themselves on startup.
-- CreateTable
CREATE TABLE "tool_versions" (
"id" TEXT NOT NULL,
"tool" TEXT NOT NULL,
"machineName" TEXT NOT NULL,
"version" TEXT NOT NULL,
"buildRef" TEXT,
"hostUser" TEXT,
"hostApp" TEXT,
"details" JSONB,
"firstSeenAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
"lastSeenAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
CONSTRAINT "tool_versions_pkey" PRIMARY KEY ("id")
);
-- CreateIndex
CREATE INDEX "tool_versions_tool_idx" ON "tool_versions"("tool");
-- CreateIndex
CREATE UNIQUE INDEX "tool_versions_tool_machineName_key" ON "tool_versions"("tool", "machineName");