feat!: Generalize build strategy terminology and add Kotlin build tools #189
Conversation
…tools - Rename ToolDomain.MANIFEST_CHECKS to ToolDomain.VALIDATION - Rename ToolDomain.MANIFEST_TESTS to ToolDomain.TESTING - Update BuildStrategy base class method names: - register_manifest_check_tools -> register_validation_tools - register_manifest_test_tools -> register_testing_tools - Update all strategy implementations (declarative_yaml_v1, declarative_openapi_v3, kotlin_source, kotlin_destination) - Update all module files to use new domain names - Add new Kotlin build tools: - compile_and_build: Compile and build Kotlin connector projects - run_unit_tests: Run unit tests for Kotlin connectors - run_integration_tests: Run integration tests for Kotlin connectors These changes make the terminology generic and applicable to both YAML manifests and Kotlin connectors. Co-Authored-By: AJ Steers <[email protected]>
Original prompt from AJ Steers |
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
📝 WalkthroughWalkthroughRefactors tool registration names and ToolDomain enums across build strategies: renames manifest-check/test registration functions to validation/testing, updates ToolDomain members, removes several Changes
Sequence Diagram(s)Not applicable — changes are API/enum renames, decorator updates, and additions of tool functions without new control-flow interactions. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
🔇 Additional comments (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
👋 Welcome to the Airbyte Connector Builder MCP!Thank you for your contribution! Here are some helpful tips and reminders for your convenience. Testing This Branch via MCPTo test the changes in this specific branch with an MCP client like Claude Desktop, use the following configuration: {
"mcpServers": {
"connector-builder-mcp-dev": {
"command": "uvx",
"args": ["--from", "git+https://github.com/airbytehq/connector-builder-mcp.git@devin/1763596878-generalize-build-strategy-terminology", "connector-builder-mcp"]
}
}
}Testing This Branch via CLIYou can test this version of the MCP Server using the following CLI snippet: # Run the CLI from this branch:
uvx 'git+https://github.com/airbytehq/connector-builder-mcp.git@devin/1763596878-generalize-build-strategy-terminology#egg=airbyte-connector-builder-mcp' --helpPR Slash CommandsAirbyte Maintainers can execute the following slash commands on your PR:
AI Builder EvaluationsAI builder evaluations run automatically under the following conditions:
A set of standardized evaluations also run on a schedule (Mon/Wed/Fri at midnight UTC) and can be manually triggered via workflow dispatch. Helpful ResourcesIf you have any questions, feel free to ask in the PR comments or join our Slack community. |
- Update MANIFEST_CHECKS -> VALIDATION - Update MANIFEST_TESTS -> TESTING This completes the refactoring by updating all references to the old domain names. Co-Authored-By: AJ Steers <[email protected]>
devin-ai-integration
bot
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_tests.py (1)
1-5: Reconcilevalidate_manifestdomain with ToolDomain semanticsThe MANIFEST_TESTS→TESTING rename is applied consistently across the decorators and
register_testing_tools, but there’s now a semantic mismatch:
validate_manifestis still decorated asdomain=ToolDomain.TESTING, even though it performs static manifest validation and does not run the connector.- In
connector_builder_mcp/mcp/_mcp_utils.ToolDomain, the VALIDATION domain is documented for “Validation tools that don't run the connector (validate_manifest, validate_kotlin_source_connector)”, while TESTING is for tools that actually run the connector.You may want to either:
- Move
validate_manifest(and its associated result model) into the VALIDATION domain (decorator + correspondingregister_validation_toolsin the checks module), or- Update the ToolDomain docs and this module’s top-level docstring to explicitly note that manifest validation is intentionally surfaced under the TESTING domain here.
Right now the behavior and the ToolDomain documentation are out of sync, which can be confusing when discovering tools by domain.
Also applies to: 482-488, 545-552, 843-849, 1145-1149, 1220-1226
🧹 Nitpick comments (2)
connector_builder_mcp/build_strategies/kotlin_source/manifest_tests.py (2)
19-38: Avoid mutable list defaults on pydantic modelsUsing
[]as a default forerrorsandwarningsonKotlinBuildResultanderrorsonKotlinTestResultcan be surprising with mutable defaults; pydantic recommendsdefault_factory=listfor these cases. Consider updating as follows:class KotlinBuildResult(BaseModel): @@ - errors: list[str] = [] - warnings: list[str] = [] + errors: list[str] = Field(default_factory=list) + warnings: list[str] = Field(default_factory=list) @@ class KotlinTestResult(BaseModel): @@ - errors: list[str] = [] + errors: list[str] = Field(default_factory=list)You may also want to apply the same pattern to
KotlinStreamTestResult.errorsfor consistency.
91-128: run_unit_tests stub is well‑shaped but could later surface more detailThe
run_unit_teststool follows the same pattern ascompile_and_build, returning a clear failure whenproject_pathis missing and a success placeholder result otherwise; this is consistent with the PR intent. When you implement this for real, consider populatingtests_run/tests_passed/tests_failedand optionally adding atest_outputfield to the success case rather than leaving everything at zero.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
connector_builder_mcp/build_strategies/base/build_strategy.py(4 hunks)connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py(1 hunks)connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_checks.py(3 hunks)connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_tests.py(3 hunks)connector_builder_mcp/build_strategies/declarative_yaml_v1/build_strategy.py(1 hunks)connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_checks.py(3 hunks)connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_tests.py(6 hunks)connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py(1 hunks)connector_builder_mcp/build_strategies/kotlin_destination/manifest_checks.py(3 hunks)connector_builder_mcp/build_strategies/kotlin_destination/manifest_tests.py(3 hunks)connector_builder_mcp/build_strategies/kotlin_source/build_strategy.py(1 hunks)connector_builder_mcp/build_strategies/kotlin_source/manifest_checks.py(3 hunks)connector_builder_mcp/build_strategies/kotlin_source/manifest_tests.py(4 hunks)connector_builder_mcp/mcp/_mcp_utils.py(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: aaronsteers
Repo: airbytehq/connector-builder-mcp PR: 116
File: .github/workflows/ci-tests.yml:110-113
Timestamp: 2025-10-10T17:09:02.151Z
Learning: The connector-builder-mcp repository (airbytehq/connector-builder-mcp) is an internal/private repository that doesn't accept external contributions, so there are no forked PRs to consider in workflow configurations.
🧬 Code graph analysis (13)
connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_checks.py (4)
connector_builder_mcp/mcp/_mcp_utils.py (2)
ToolDomain(49-80)register_mcp_tools(246-279)connector_builder_mcp/build_strategies/base/build_strategy.py (1)
register_validation_tools(78-84)connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py (1)
register_validation_tools(45-47)connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_checks.py (1)
register_validation_tools(91-97)
connector_builder_mcp/build_strategies/kotlin_source/manifest_checks.py (3)
connector_builder_mcp/mcp/_mcp_utils.py (2)
ToolDomain(49-80)register_mcp_tools(246-279)connector_builder_mcp/build_strategies/base/build_strategy.py (1)
register_validation_tools(78-84)connector_builder_mcp/build_strategies/kotlin_source/build_strategy.py (1)
register_validation_tools(61-63)
connector_builder_mcp/build_strategies/declarative_yaml_v1/build_strategy.py (4)
connector_builder_mcp/build_strategies/base/build_strategy.py (2)
register_validation_tools(78-84)register_testing_tools(88-94)connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py (2)
register_validation_tools(45-47)register_testing_tools(50-52)connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_checks.py (1)
register_validation_tools(93-99)connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_tests.py (1)
register_testing_tools(1220-1226)
connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_tests.py (8)
connector_builder_mcp/mcp/_mcp_utils.py (2)
ToolDomain(49-80)register_mcp_tools(246-279)connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py (1)
register_testing_tools(50-52)connector_builder_mcp/build_strategies/declarative_yaml_v1/build_strategy.py (1)
register_testing_tools(54-56)connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_tests.py (1)
register_testing_tools(1220-1226)connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py (1)
register_testing_tools(66-68)connector_builder_mcp/build_strategies/kotlin_destination/manifest_tests.py (1)
register_testing_tools(95-101)connector_builder_mcp/build_strategies/kotlin_source/build_strategy.py (1)
register_testing_tools(66-68)connector_builder_mcp/build_strategies/kotlin_source/manifest_tests.py (1)
register_testing_tools(244-250)
connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_checks.py (9)
connector_builder_mcp/mcp/_mcp_utils.py (2)
ToolDomain(49-80)register_mcp_tools(246-279)connector_builder_mcp/build_strategies/base/build_strategy.py (1)
register_validation_tools(78-84)connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py (1)
register_validation_tools(45-47)connector_builder_mcp/build_strategies/declarative_yaml_v1/build_strategy.py (1)
register_validation_tools(49-51)connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_checks.py (1)
register_validation_tools(93-99)connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py (1)
register_validation_tools(61-63)connector_builder_mcp/build_strategies/kotlin_destination/manifest_checks.py (1)
register_validation_tools(76-82)connector_builder_mcp/build_strategies/kotlin_source/build_strategy.py (1)
register_validation_tools(61-63)connector_builder_mcp/build_strategies/kotlin_source/manifest_checks.py (1)
register_validation_tools(76-82)
connector_builder_mcp/build_strategies/kotlin_source/manifest_tests.py (3)
connector_builder_mcp/mcp/_mcp_utils.py (3)
ToolDomain(49-80)mcp_tool(102-149)register_mcp_tools(246-279)connector_builder_mcp/build_strategies/base/build_strategy.py (1)
register_testing_tools(88-94)connector_builder_mcp/build_strategies/kotlin_source/build_strategy.py (1)
register_testing_tools(66-68)
connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py (3)
connector_builder_mcp/build_strategies/base/build_strategy.py (2)
register_validation_tools(78-84)register_testing_tools(88-94)connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_checks.py (1)
register_validation_tools(91-97)connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_tests.py (1)
register_testing_tools(94-100)
connector_builder_mcp/build_strategies/kotlin_destination/manifest_tests.py (2)
connector_builder_mcp/mcp/_mcp_utils.py (2)
ToolDomain(49-80)register_mcp_tools(246-279)connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py (1)
register_testing_tools(66-68)
connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py (3)
connector_builder_mcp/build_strategies/base/build_strategy.py (2)
register_validation_tools(78-84)register_testing_tools(88-94)connector_builder_mcp/build_strategies/kotlin_destination/manifest_checks.py (1)
register_validation_tools(76-82)connector_builder_mcp/build_strategies/kotlin_destination/manifest_tests.py (1)
register_testing_tools(95-101)
connector_builder_mcp/build_strategies/kotlin_source/build_strategy.py (4)
connector_builder_mcp/build_strategies/base/build_strategy.py (2)
register_validation_tools(78-84)register_testing_tools(88-94)connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py (2)
register_validation_tools(61-63)register_testing_tools(66-68)connector_builder_mcp/build_strategies/kotlin_source/manifest_checks.py (1)
register_validation_tools(76-82)connector_builder_mcp/build_strategies/kotlin_source/manifest_tests.py (1)
register_testing_tools(244-250)
connector_builder_mcp/build_strategies/kotlin_destination/manifest_checks.py (9)
connector_builder_mcp/mcp/_mcp_utils.py (2)
ToolDomain(49-80)register_mcp_tools(246-279)connector_builder_mcp/build_strategies/base/build_strategy.py (1)
register_validation_tools(78-84)connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py (1)
register_validation_tools(45-47)connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_checks.py (1)
register_validation_tools(91-97)connector_builder_mcp/build_strategies/declarative_yaml_v1/build_strategy.py (1)
register_validation_tools(49-51)connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_checks.py (1)
register_validation_tools(93-99)connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py (1)
register_validation_tools(61-63)connector_builder_mcp/build_strategies/kotlin_source/build_strategy.py (1)
register_validation_tools(61-63)connector_builder_mcp/build_strategies/kotlin_source/manifest_checks.py (1)
register_validation_tools(76-82)
connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_tests.py (8)
connector_builder_mcp/mcp/_mcp_utils.py (2)
ToolDomain(49-80)register_mcp_tools(246-279)connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py (1)
register_testing_tools(50-52)connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_tests.py (1)
register_testing_tools(94-100)connector_builder_mcp/build_strategies/declarative_yaml_v1/build_strategy.py (1)
register_testing_tools(54-56)connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py (1)
register_testing_tools(66-68)connector_builder_mcp/build_strategies/kotlin_destination/manifest_tests.py (1)
register_testing_tools(95-101)connector_builder_mcp/build_strategies/kotlin_source/build_strategy.py (1)
register_testing_tools(66-68)connector_builder_mcp/build_strategies/kotlin_source/manifest_tests.py (1)
register_testing_tools(244-250)
connector_builder_mcp/build_strategies/base/build_strategy.py (9)
connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py (2)
register_validation_tools(45-47)register_testing_tools(50-52)connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_checks.py (1)
register_validation_tools(91-97)connector_builder_mcp/build_strategies/declarative_yaml_v1/build_strategy.py (2)
register_validation_tools(49-51)register_testing_tools(54-56)connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_checks.py (1)
register_validation_tools(93-99)connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py (2)
register_validation_tools(61-63)register_testing_tools(66-68)connector_builder_mcp/build_strategies/kotlin_destination/manifest_checks.py (1)
register_validation_tools(76-82)connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_tests.py (1)
register_testing_tools(94-100)connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_tests.py (1)
register_testing_tools(1220-1226)connector_builder_mcp/build_strategies/kotlin_destination/manifest_tests.py (1)
register_testing_tools(95-101)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Pytest (Fast)
- GitHub Check: Pytest (All, Python 3.11, Ubuntu)
- GitHub Check: Pytest (All, Python 3.10, Ubuntu)
🔇 Additional comments (27)
connector_builder_mcp/mcp/_mcp_utils.py (1)
61-65: LGTM! Terminology successfully generalized.The enum value renames from
MANIFEST_CHECKS→VALIDATIONandMANIFEST_TESTS→TESTINGmake the domains more strategy-agnostic and applicable to both declarative and Kotlin connectors. The updated docstrings clearly distinguish validation (static checks without running) from testing (runtime execution).connector_builder_mcp/build_strategies/kotlin_destination/manifest_checks.py (3)
1-5: LGTM! Module docstring updated correctly.The module docstring now uses "VALIDATION domain tools" which aligns with the generalized terminology and correctly describes the purpose of static validation without running the connector.
28-33: LGTM! Decorator domain updated consistently.The decorator now uses
ToolDomain.VALIDATIONinstead of the old manifest-specific naming, maintaining consistency with the refactored enum values.
76-82: LGTM! Function renamed and registration updated.The function rename from
register_manifest_check_toolstoregister_validation_toolsis consistent with the API refactoring, and the domain parameter correctly referencesToolDomain.VALIDATION.connector_builder_mcp/build_strategies/base/build_strategy.py (3)
27-38: LGTM! Documentation updated to reflect generalized domains.The docstring comments now use "Validation" and "Testing" instead of manifest-specific terminology, correctly describing these as strategy-specific variable domains.
76-94: LGTM! Abstract method signatures updated consistently.The abstract methods have been renamed from
register_manifest_check_tools→register_validation_toolsandregister_manifest_test_tools→register_testing_tools. This establishes the new API contract for all concrete strategy implementations.
107-120: LGTM! Orchestration method updated with new method names.The
register_all_mcp_callablesmethod now correctly calls the renamed registration methods, maintaining the proper registration order.connector_builder_mcp/build_strategies/declarative_yaml_v1/build_strategy.py (1)
48-56: LGTM! Concrete strategy implementation updated consistently.The method renames from
register_manifest_check_tools→register_validation_toolsandregister_manifest_test_tools→register_testing_toolscorrectly implement the updated abstract base class contract. The delegation to the renamed module functions (manifest_checks.register_validation_toolsandmanifest_tests.register_testing_tools) is consistent.connector_builder_mcp/build_strategies/declarative_yaml_v1/manifest_checks.py (3)
1-5: LGTM! Module docstring updated to use VALIDATION domain.The docstring correctly describes this as "VALIDATION domain tools" and clarifies that these tools validate without running the connector.
29-34: LGTM! Tool decorator updated to VALIDATION domain.The
validate_manifesttool now correctly usesToolDomain.VALIDATIONinstead of the old manifest-specific domain.
93-99: LGTM! Registration function renamed and domain updated.The function rename to
register_validation_toolsand the updated domain reference toToolDomain.VALIDATIONare consistent with the refactoring pattern.connector_builder_mcp/build_strategies/kotlin_destination/manifest_tests.py (3)
1-5: LGTM! Module docstring updated to use TESTING domain.The docstring correctly describes this as "TESTING domain tools" and clarifies that these tools run the connector against the destination system.
28-33: LGTM! Tool decorator updated to TESTING domain.The
test_kotlin_destination_writetool now correctly usesdomain=ToolDomain.TESTINGinstead of the old manifest-specific domain.
95-101: LGTM! Registration function renamed and domain updated.The function rename to
register_testing_toolsand the updated domain reference toToolDomain.TESTINGare consistent with the refactoring pattern.connector_builder_mcp/build_strategies/kotlin_destination/build_strategy.py (1)
60-68: LGTM! Kotlin destination strategy updated consistently.Both registration methods have been renamed to
register_validation_toolsandregister_testing_tools, correctly implementing the updated abstract base class contract. The delegation to the renamed module functions is consistent.connector_builder_mcp/build_strategies/kotlin_source/manifest_checks.py (3)
1-5: LGTM! Module docstring updated to use VALIDATION domain.The docstring correctly describes this as "VALIDATION domain tools" for Kotlin source connectors, maintaining consistency with other validation modules.
28-33: LGTM! Tool decorator updated to VALIDATION domain.The
validate_kotlin_source_connectortool now correctly usesToolDomain.VALIDATIONinstead of the old manifest-specific domain.
76-82: LGTM! Registration function renamed and domain updated.The function rename to
register_validation_toolsand the updated domain reference toToolDomain.VALIDATIONcomplete the consistent refactoring across all build strategies.connector_builder_mcp/build_strategies/kotlin_source/build_strategy.py (1)
61-68: Validation/testing registration wiring looks correct
register_validation_toolsandregister_testing_toolsnow delegate to the correspondingmanifest_checks/manifest_testshelpers, matching the updated BuildStrategy API and ToolDomain semantics. This keeps Kotlin source strategy aligned with the Kotlin destination and base strategy patterns.connector_builder_mcp/build_strategies/declarative_openapi_v3/build_strategy.py (1)
45-52: OpenAPI strategy registration updated consistently to validation/testingThe strategy now uses
register_validation_tools/register_testing_toolsand delegates to the corresponding manifest modules, matching the new baseBuildStrategyAPI and ToolDomain naming. No behavioral regressions apparent.connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_tests.py (1)
1-5: TESTING domain rename for OpenAPI tools is consistentThe module docstring,
@mcp_tooldecorator (domain=ToolDomain.TESTING), andregister_testing_toolshelper all align on the new TESTING domain. The placeholder behavior oftest_openapi_resourceis clearly signaled in the return message, matching the PR’s intent.Also applies to: 31-35, 94-100
connector_builder_mcp/build_strategies/declarative_openapi_v3/manifest_checks.py (1)
1-5: OpenAPI validation tool correctly mapped to VALIDATION domain
validate_openapi_specis now registered underToolDomain.VALIDATION, andregister_validation_toolsforwards toregister_mcp_toolswith the same domain. This matches both the tool’s behavior (pure spec validation) and the updated ToolDomain documentation.Also applies to: 28-33, 91-97
connector_builder_mcp/build_strategies/kotlin_source/manifest_tests.py (5)
1-5: Module docstring correctly reflects new TESTING domain terminologyThe updated docstring aligns this module with the new
ToolDomain.TESTINGterminology and clarifies that these tools are for runtime testing of Kotlin source connectors; no issues here.
53-88: compile_and_build stub behavior and domain look consistentThe
compile_and_buildtool is correctly registered underToolDomain.TESTINGwithopen_world=True, and the placeholder implementation clearly fails on missingproject_pathand returns a success result with an explicit placeholder warning otherwise. This shape should be safe to evolve into a real implementation without breaking the API.
131-180: run_integration_tests input validation and placeholder semantics are reasonableThe
run_integration_teststool correctly requires bothproject_pathandconfig, returning explicit failure results when either is missing, and otherwise returning a success placeholder with zeroed test counters. This matches the TESTING domain semantics and sets you up cleanly for a future real implementation that will useconfigand update the statistics fields.
183-186: test_kotlin_source_stream correctly moved under TESTING domainUpdating the decorator to
domain=ToolDomain.TESTINGkeeps this stream test tool aligned with the new domain contract (testing tools that run the connector) and consistent with how it’s referenced inToolDomaindocs and the Kotlin build strategy. No further changes needed here.
244-250: register_testing_tools correctly wires this module into the TESTING domainThe new
register_testing_toolshelper delegates toregister_mcp_tools(app, domain=ToolDomain.TESTING), which matches theBuildStrategy.register_testing_toolsexpectation and ensures all tools in this module get registered under the testing domain. This looks correct and keeps the strategy wiring straightforward.
aaronsteers
deleted the
devin/1763596878-generalize-build-strategy-terminology
branch
refactor: Generalize build strategy terminology and add Kotlin build tools
Summary
This PR makes the build strategy terminology more generic so it applies equally to both YAML manifest-based connectors and Kotlin-based connectors. The main changes are:
Renamed ToolDomain enum values to be strategy-agnostic:
MANIFEST_CHECKS→VALIDATIONMANIFEST_TESTS→TESTINGRenamed BuildStrategy abstract methods to match:
register_manifest_check_tools()→register_validation_tools()register_manifest_test_tools()→register_testing_tools()Updated all strategy implementations (declarative_yaml_v1, declarative_openapi_v3, kotlin_source, kotlin_destination) and their module files to use the new terminology
Added three new placeholder tools for Kotlin source connectors:
compile_and_build()- Compile and build Kotlin connector projectsrun_unit_tests()- Run unit tests for Kotlin connectorsrun_integration_tests()- Run integration tests for Kotlin connectorsThe refactoring is purely a rename with no logic changes. The new Kotlin tools are placeholder implementations that return success with warnings indicating they need real implementation.
Review & Testing Checklist for Human
MANIFEST_CHECKS,MANIFEST_TESTS) have been updated throughout the codebase, including any documentation or commentspoe test)compile_and_build,run_unit_tests,run_integration_tests) are stubs that don't actually execute builds or tests - they just return success with warningsTest Plan
poe testto ensure all tests passpoe serverand usepoe inspectto verify tools are registered under the new domain names (validationandtestinginstead ofmanifest_checksandmanifest_tests)Notes
BuildStrategyor references the old domain enum valuesRequested by: AJ Steers ([email protected]) via Slack (#ask-devin-ai)
Devin session: https://app.devin.ai/sessions/05cef87d69ce458db25de9c3422e582b
Summary by CodeRabbit
Refactor
New Features
✏️ Tip: You can customize this high-level summary in your review settings.