fix(engine): m test --docker layers the resident routine base (gtmroutines fallback)#8
Merged
Merged
Conversation
…tines fallback)
DockerRunner exported `ydb_routines="<stageDir> $ydb_routines"`. For a bare YDB
image (m-test-engine) that is correct, but a GT.M-configured VistA (FOIA vehu)
sets `gtmroutines`, not `ydb_routines` — so the ambient `$ydb_routines` is empty,
the export became stageDir-only, and since GT.M honors `ydb_routines` over
`gtmroutines` once set, vehu's resident VistA routines (XPAR, FileMan, XLFDT)
vanished from the path. VistA-dependent suites faulted before report^STDASSERT
(0/0). (Globals were fine: docker.go never sets ydb_gbldir, so the ambient
gtmgbldir survives.)
Fix: extract `dockerEnvPrefix(stageDir)` and fall back to the GT.M name —
`ydb_routines="<stageDir> ${ydb_routines:-$gtmroutines}"`. Bare YDB unchanged
(ydb_routines set); GT.M VistA now resolves both staged and resident routines.
TDD red→green table test in docker_test.go.
Validated end-to-end: v-stdlib VSLCFGTST (XPAR config adapter) 0/0 → 3/3 GREEN on
BOTH engines via the driver stack — `m test --docker vehu` (YDB) and
`--docker foia-t12 --namespace VISTA` (IRIS, needed no change). m-test-engine
regression 2/2. make lint + go test ./... clean. Unblocks all VistA-dependent
VSL*TST testing (the m-cli DockerEngine analog of the m-ydb $ZGBLDIR fix).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
m test --docker <vista>uses m-cli's internal DockerEngine, which exportedydb_routines="<stageDir> $ydb_routines". A GT.M-configured VistA (FOIAvehu) setsgtmroutines, notydb_routines— so the export went stageDir-only and (GT.M honorsydb_routinesovergtmroutines) the engine's resident VistA routines (XPAR, FileMan, XLFDT) vanished from the path → VistA-dependent suites faulted 0/0.Fix: extract
dockerEnvPrefix+ fall back to${ydb_routines:-$gtmroutines}. Bare YDB (m-test-engine) unchanged; GT.M VistA now resolves staged + resident routines. TDD red→green table test.Validated: v-stdlib
VSLCFGTST(XPAR config adapter) 0/0 → 3/3 GREEN on vehu (YDB) and foia-t12 (IRIS--namespace VISTA); m-test-engine regression 2/2;make lint+go test ./...clean. Unblocks all VistA-dependentVSL*TSTtesting (the DockerEngine analog of the m-ydb$ZGBLDIRfix).🤖 Generated with Claude Code