-
Notifications
You must be signed in to change notification settings - Fork 144
Add buildArgs support for baking arguments into container ENTRYPOINTs #2631
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft
danbarr
wants to merge
11
commits into
main
Choose a base branch
from
add-buildargs-to-protocol-builds
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+297
−13
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
- Add BuildArgs field to TemplateData struct for baking required CLI arguments into container ENTRYPOINT at build time - Update npx.tmpl to insert BuildArgs before "$@" - Update uvx.tmpl to insert BuildArgs before "$@" - Update go.tmpl to insert BuildArgs in JSON array format BuildArgs are for required subcommands (e.g., 'start') while runtime args passed via '-- <args>' append after. This prevents duplication issues that led to MCPArgs removal in PR #2630. Related to: stacklok/dockyard#189
- Add buildArgs []string parameter to BuildFromProtocolSchemeWithName - Update createTemplateData to accept and use buildArgs - Update HandleProtocolScheme to pass nil for buildArgs - Update thv build command callers to pass nil for buildArgs Existing callers pass nil to maintain backward compatibility.
Fixed extra quote in ENTRYPOINT template that was causing test failures. The template now correctly generates: - Empty buildArgs: ENTRYPOINT ["/app/mcp-server"] - With buildArgs: ENTRYPOINT ["/app/mcp-server", "arg1", "arg2"]
Added test cases for all three transport types (NPX, UVX, GO) that exercise the BuildArgs feature: - NPX with single arg (start) - UVX with multiple args (--transport stdio) - GO with multiple args (serve --verbose) All tests verify that BuildArgs are correctly baked into the ENTRYPOINT.
Users can now bake required arguments into containers at build time: $ thv build npx://@launchdarkly/mcp-server -- start $ thv build uvx://package -- --transport stdio This provides: - Consistency with 'thv run -- <args>' syntax - Easy local testing of build args before using in Dockyard - Arguments are baked into ENTRYPOINT, not overridable at runtime Examples: - NPX: exec npx package start "$@" - UVX: exec package "--transport" "stdio" - GO: ENTRYPOINT ["/app/mcp-server", "serve", "--verbose"] Related to: stacklok/dockyard#189
- Updated TestTemplateDataWithLocalPath to include BuildArgs field - Added TestCreateTemplateData with 5 test cases covering: * NPX with single buildArg * UVX with multiple buildArgs * GO with buildArgs * GO local path with buildArgs * NPX without buildArgs (backward compatibility) All tests verify that buildArgs flow correctly through the createTemplateData function and are properly set in TemplateData.
- Broke up long line in build.go (BuildFromProtocolSchemeWithName call) - Broke up long function signature in protocol.go (createTemplateData) Both lines now conform to 130 character limit.
Signed-off-by: Dan Barr <[email protected]>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2631 +/- ##
==========================================
+ Coverage 55.47% 55.57% +0.10%
==========================================
Files 312 312
Lines 29714 29715 +1
==========================================
+ Hits 16483 16515 +32
+ Misses 11791 11758 -33
- Partials 1440 1442 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Collaborator
|
@claude do a thorough review of this |
Contributor
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
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.
Summary
Adds support for baking required CLI arguments into container ENTRYPOINTs at build time, addressing Dockyard issue #189.
Some MCP servers (like LaunchDarkly) require specific subcommands that must always be present. This feature allows those arguments to be embedded in the container image, preventing users from accidentally overwriting them.
Note: This PR implements the ToolHive side of the feature. Once released, Dockyard will need to be updated to pass
spec.argstoBuildFromProtocolSchemeWithName(see stacklok/dockyard#189).Changes
buildArgs []stringparameter toBuildFromProtocolSchemeWithNameandcreateTemplateData"$@"thv buildCLI to accept-- <args>syntax for baking argumentsExamples
Implementation Details
nilfor backward compatibility"$@"so runtime args append naturallyTesting
Next Steps
This enables Dockyard to pass
spec.argsto the build system for servers requiring specific subcommands.