feat(ci): engine-ci runs the tests via a Fallout TestEngine target - #301
Merged
Conversation
Closes #299. engine-ci only ran `dotnet restore` + `dotnet build`, so a green check meant "it compiles" and nothing more — the engine's 123 tests (idempotency, the nested-userns guard, the rootless posture) had never executed in CI at all. Driven through Fallout rather than raw `dotnet`, so the repo keeps ONE build entrypoint (ADR-0001) and CI can't drift from what runs locally — the same reason power-orchestrator-ci calls `./build.sh TestPowerOrchestrator` (which, checked while here, does already run its tests). - build/Build.cs: `TestEngine` target, DependsOn(CompileEngine). No --no-build, because CompileEngine builds the engine project only — not the test project (unlike PowerOrchestrator, where Compile builds the whole solution). - Zero-tests guard: `dotnet test` exits 0 when it discovers nothing, so a renamed or moved test project would leave the gate green while testing nothing. The target parses the run total and throws if it's zero. Verified: exit 255 with a filter matching no tests, exit 0 normally. - engine-ci.yml: `./build.sh TestEngine`, and the paths trigger now includes Infrastructure/engine.Tests/** (a test-only PR previously didn't run CI at all), Infrastructure/schema/** (the catalogue drift-guard test reads it), build/** and global.json. - engine-ci now needs secrets.PACKAGES_PAT rather than GITHUB_TOKEN: going through Fallout means restoring Fallout.* from the Fallout-build org's GitHub Packages feed, and the default GITHUB_TOKEN cannot read packages across orgs. The new gate immediately caught a real defect on its first run — a test I added in #294 asserted a MISSING secret using MATE_AUTH_PASSWORD as the example key, and that key became REAL an hour earlier (#285). SecretsEnv.Load(null) deliberately folds in process env vars, so the test passed or failed depending on whether the developer had sourced secrets.env. Now uses a sentinel key per the HL<issue>_TEST_* convention already established in ConvergeCoreTests, with a comment explaining why it must never be a realistic name. .fallout/build.schema.json regenerates to include TestEngine (and PublishValidator, which had never been captured). Closes #299
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #299.
engine-cionly randotnet restore+dotnet build, so a green check meant "it compiles" and nothing more. The engine's 123 tests — idempotency, the nested-userns guard, the rootless posture — had never executed in CI.Approach
Driven through Fallout, not raw
dotnet, so the repo keeps one build entrypoint (ADR-0001) and CI can't drift from what runs locally. That's the same reasonpower-orchestrator-cicalls./build.sh TestPowerOrchestrator— which, checked while here, does already run its tests, so the engine was the only gap.build/Build.cs— newTestEnginetarget,DependsOn(CompileEngine). No--no-build:CompileEnginebuilds the engine project only, not the test project (unlike PowerOrchestrator, where Compile builds the whole solution).dotnet testexits 0 when it discovers nothing, so a renamed or moved test project would keep the gate green while testing nothing. The target parses the run total and throws if it's zero. Verified both ways: exit 255 with a filter matching no tests, exit 0 normally.engine-ci.yml— runs./build.sh TestEngine;paths:now also coversInfrastructure/engine.Tests/**(a test-only PR previously didn't trigger CI at all),Infrastructure/schema/**(the catalogue drift-guard test reads it),build/**andglobal.json.secrets.PACKAGES_PATreplacesGITHUB_TOKEN— going through Fallout means restoringFallout.*from the Fallout-build org's GitHub Packages feed, and the defaultGITHUB_TOKENcannot read packages across orgs.The gate caught a real defect on its very first run
A test added in #294 asserted a missing secret using
MATE_AUTH_PASSWORDas the example key — and that key became real an hour earlier via #285. SinceSecretsEnv.Load(null)deliberately folds in process env vars, the test passed or failed depending on whether the developer had sourcedsecrets.env.Fixed to use a sentinel key per the
HL<issue>_TEST_*convention already established inConvergeCoreTests, with a comment explaining why it must never be a realistic name. Local run withsecrets.envsourced — the previously-failing condition — is green at 123 tests..fallout/build.schema.jsonregenerates to includeTestEngine(andPublishValidator, which had never been captured).This PR should be gated by the thing it adds — it touches
build/**,engine.Tests/**and the workflow, soengine-ciruns on it.🤖 Generated with Claude Code