Release gates
Tools/RunReleaseGates.ps1 runs every release gate in turn, from clean builds to a soak of the packaged game and an update and rollback, and calls the build a release candidate only when every gate is green.
Run the gates
The gates run one after another; a full run takes hours, so start it in the background. -Gates reruns a few gates (wildcards allowed); such a run is never a release candidate. -SkipBuild uses the existing binaries.
PowerShell
powershell -File Tools/RunReleaseGates.ps1 # every gate powershell -File Tools/RunReleaseGates.ps1 -SoakSeconds 600 -ServerSoakMinutes 30 powershell -File Tools/RunReleaseGates.ps1 -SkipBuild -Gates soak-player,update-rollback
The gates
| Gate | Passes when |
|---|---|
build-debug, build-release | Configure and the whole build matrix succeed in both configurations |
ctest-debug, ctest-release | Every CTest case passes, with KROYS_TEST_SHORT_PATHS=1 as in CI |
RenderRegression | Every render fixture matches its baseline |
| Acceptance scripts | Every Tools/Run*Acceptance.ps1 in full validation passes (in Debug, the configuration their timings are tuned for) |
PackageAcceptance | Two Release packages of the test game (scripts compiled while packaging) are byte-identical and the player boots from the extracted ZIP |
HeadlessServer | The Release headless server build contains no forbidden target or import and starts and stops cleanly |
performance | The heavy-scene frame, CPU, GPU and shadow times stay within Config/PerformanceBudget.json |
soak-player | The packaged player runs for the soak time without crashing, logs no error and its memory growth stays under the bound |
soak-server | A dedicated server on 127.0.0.1 with simulated clients runs without crashing or logging errors; memory and handles stay bounded |
clean-install | The package runs from an extracted folder with only the Windows system folders on PATH and an isolated user profile |
update-rollback | Package N installs, N+1 installs over it, N is restored; every installation boots and the user's settings and save games survive |
distribution | The engine download builds and matches its checksum; unpacked with a scrubbed environment, its editor creates a project from a template and plays it, its .NET SDK builds a C# plugin sample, its packager packages the project and the packaged game boots (Releases) |
The acceptance scripts are read from full.scripts in Config/ValidationMap.json, so a new acceptance script joins the gates once it is in the map (Change-based validation).
Thresholds
Config/ReleaseGates.json holds the acceptance and package configurations, the soak lengths, sampling, memory-growth bounds (the larger of an absolute and a relative limit, after a warm-up), the server soak's clients and network profile, and the boot time limit. Performance budgets are machine-specific; refresh them on the reference machine with Tools/RunPerformanceGate.ps1 -UpdateBudget.
Clean environment and isolation
Every program a gate starts gets its own scratch user settings folder (KROYS_USER_SETTINGS_DIR), binds sockets to 127.0.0.1 (KROYS_NET_BIND) and never shows a dialog (KROYS_NO_DIALOGS). The install gates go further: the player starts with an environment holding only the Windows system variables, PATH limited to the Windows folders, no SDK or .NET variables, and its own user profile, temporary and application data folders. Every process is closed at the end of its gate; windows are closed with a close request, not input.
Update and rollback
The gate installs the package acceptance's ZIP (N) by extracting it next to the installation and swapping folders, boots it, then writes a save game and a settings file into the user folder. It packages N+1 from the same scratch project with a different window title, installs it over N (keeping N for a rollback), and checks that the installation holds exactly N+1's files, that it boots and that all user files are still there and unchanged. Rolling back restores N and checks the same again.
The report
Artifacts/ReleaseGates/<timestamp>/report.json and report.md list every gate with its result, duration and details: failed cases, measured budgets, memory samples, boot times. Logs of each gate sit next to them. The script exits with 0 only for a release candidate.
Manual: a clean virtual machine
The automated gates run on the development machine with a scrubbed environment. Installing on a machine that never had developer tools (a fresh virtual machine with only a graphics driver) stays manual: follow the clean-machine check for the engine download and a packaged game before a release is published.
KroysEngine 0.1.0 documentation, built from the engine repository by Tools/BuildDocsSite.py.