Repository navigation
fix(runtime): honor DOCKER_CONTEXT when selecting the Docker endpoint - #40
Merged
Merged
Conversation
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.
An explicit
DOCKER_CONTEXTis ignored when Strix chooses its local Docker endpoint. If the stored active context points elsewhere, a run can select the wrong daemon even though the requested named context exists.This backports usestrix#1612 to fork
masterat8aa0791e, addressing usestrix#1610. Context selection now honors a nonblankDOCKER_CONTEXTbefore consulting Docker's stored current context, while preserving the existingDOCKER_HOSTprecedence. The configuration docs andFORK.mdrecord this behavior.Validation on the fork, Python 3.12.14 and frozen dependencies, with isolated HOME/environment:
test_docker_connection.py,test_docker_client_delete.py,test_session_entries.pyandtest_network_guard.py.git diff --checkpassed.make check-allreaches the existing Pyright failure: base and patch both report 1,259 errors, with identical diagnostic signatures after normalizing checkout paths.Tests use real temporary Docker context metadata and mocked client connections. A real Docker daemon or scan was not exercised, and the complete Python suite was not run. Version stamping and release remain part of the merge/delivery procedure.
Remote CI: GitHub Actions run could not start its jobs because the account is locked due to a billing issue. No remote validation was performed.