尧图网页设计 
OpenMetadata Connector Validator 实战指南用 5 项检查自动校验连接器实现是否符合标准【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata本文以 OpenMetadata 仓库中的 Connector Validator Agent 定义 为核心完整讲解如何对一个连接器Connector实现执行 Schema、Python 结构、Test Connection、注册与代码质量五类自动化校验。读完本文你将掌握这套校验的每一条判定规则、底层依据与修复路径能够独立审查任意新增连接器如ingestion/src/metadata/ingestion/source/database/my_db/是否达到 OpenMetadata 的合入标准。校验器在连接器开发生命周期中的位置OpenMetadata 连接器采用schema-firstSchema 优先架构一份 JSON Schema 是唯一事实来源通过代码生成级联到 Python Pydantic 模型、Java 模型、TypeScript 类型、UI 配置表单、API 请求校验与测试夹具参见 main.md。因为绝不手写配置类Never hand-write config classes任何一处 Schema 或注册遗漏都会在运行期以难以定位的方式暴露——连接器不出现在 UI、渲染成默认图标、测试连接步骤找不到函数等。Connector Validator 正是针对这一痛点设计的一个校验代理validation agent给定一个连接器路径它按顺序执行 5 项确定性检查并输出[PASS]/[FAIL]/[SKIP]清单。它面向的场景包括新连接器脚手架生成后的自检PR 合入前对新增source/{service_type}/{name}/目录的审查评审 Agent 与人类 Reviewer 的辅助检查工具可参考同仓库的 connector-review SKILL 及其模板。Check 1Schema Validation——JSON Schema 的 5 个硬性字段第一步读取连接 Schema JSON 文件其标准位置为openmetadata-spec/src/main/resources/json/schema/entity/services/connections/{service_type}/{moduleName}Connection.json见 schema.md。校验项包括顶层字段完备$id完整 URI 路径、$schemahttp://json-schema.org/draft-07/schema#、titlePascalCase 连接名、javaType完整 Java 类路径、type: object、additionalProperties: false必须全部存在。additionalProperties: false用于阻止 UI/API 传入未声明字段是防止配置漂移的关键。definitions 类型枚举definitions块中必须有一个类型枚举如myDbType枚举值即服务类型名如MyDb并带default。该枚举值会被生成进{ServiceType}Type是 UI、ServiceSpec 解析与注册链路的公共标识。$ref路径可达性所有$ref指向的仓库文件必须真实存在。常见共享引用包括能力标志../connectionBasicType.json#/definitions/supportsMetadataExtraction、SSL 配置../../../../security/ssl/verifySSLConfig.json#/definitions/verifySSLConfig、过滤模式../../../../type/filterPattern.json#/definitions/filterPattern、认证./common/basicAuth.json等。校验器需逐一解析相对路径并确认目标文件存在可通过 Grep/Glob 完成。supportsMetadataExtraction必须存在该能力标志定义于 connectionBasicType.jsondefinitions.supportsMetadataExtraction是所有连接器的必备能力。此外按能力声明supportsUsageExtraction、supportsLineageExtraction、supportsProfiler、supportsDBTExtraction等。一份最小数据库连接 Schema 的结构如下完整模板见 schema.md{ $id: https://open-metadata.org/schema/entity/services/connections/database/myDbConnection.json, $schema: http://json-schema.org/draft-07/schema#, title: MyDbConnection, description: MyDb Connection Config, type: object, javaType: org.openmetadata.schema.services.connections.database.MyDbConnection, definitions: { myDbType: { description: Service type., type: string, enum: [MyDb], default: MyDb } }, properties: { type: { $ref: #/definitions/myDbType, default: MyDb }, hostPort: { title: Host and Port, type: string, format: uri }, supportsMetadataExtraction: { $ref: ../connectionBasicType.json#/definitions/supportsMetadataExtraction } }, additionalProperties: false, required: [hostPort] }required数组也有明确规则hostPort恒为必需采用认证的服务需把username/password或token/apiKey置为必需存在多种认证方式且无合理默认时authType应为必需。判定原则是——若省略某字段会在运行期抛出不透明的认证错误就应在 Schema 中将其设为required让 UI 前置校验。Check 2Python Structure——连接器目录的四件套与版权头每个连接器位于ingestion/src/metadata/ingestion/source/{service_type}/{name}/校验器检查以下内容必备文件齐全__init__.py模块标记、connection.py创建与测试连接、metadata.py元数据抽取、service_spec.py向框架注册连接器。非数据库连接器还应有client.py数据库连接器应有queries.py具备血缘/用量能力时还应有lineage.py、usage.py、query_parser.py见 main.md 的 Connector Anatomy 表。版权头所有.py文件必须以# Copyright 2025 OpenMetadata开头的版权头内容见 code_style.md。缺失版权头是最常见的 FAIL 项例如原文示例中的client.py。service_spec.py导出ServiceSpec变量变量名必须精确为ServiceSpec大小写敏感模块名必须是service_spec.py。框架在metadata.ingestion.source.{service_type}.{name}.service_spec.ServiceSpec处动态解析它。数据库连接器用DefaultDatabaseSpec(metadata_source_class..., connection_class..., lineage_source_class..., usage_source_class...)其中DefaultDatabaseSpec会自动装配 profiler/sampler/test suite非数据库连接器用BaseSpec(metadata_source_class...)详见 service_spec.md。metadata.py含create()类方法源码类如MyDbSource通过create()完成从配置到实例的构造是拓扑处理器topology processor入口必须存在。Check 3Test Connection——步骤名与test_fn键的严格对齐读取测试连接 JSON 文件位置openmetadata-service/src/main/resources/json/data/testConnections/{service_type}/{moduleName}.json验证其中每个步骤的name都能在connection.py的test_fn字典中找到同名键。测试连接 JSON 的标准形态{ name: MyDb, displayName: MyDb Test Connection, description: Validate that we can connect and extract metadata from MyDb., steps: [ { name: CheckAccess, description: Validate access to the service, errorMessage: Failed to connect to MyDb, mandatory: true, shortCircuit: true }, { name: GetDatabases, description: List available databases, errorMessage: Failed to list databases, mandatory: true, shortCircuit: false } ] }在connection.py中test_connection()构造test_fn字典时键必须与上述name逐字精确匹配见 connection.mddef test_connection(metadata, client, service_connection, automation_workflowNone) - None: test_fn { CheckAccess: partial(test_access, client), GetDatabases: partial(test_list_databases, client), } test_connection_steps( metadatametadata, test_fntest_fn, service_typeservice_connection.type.value, automation_workflowautomation_workflow, )为什么必须严格对齐可以看底层实现 test_connections.py 的test_connection_steps()它先从服务端按service_type .testConnectionDefinition拉取TestConnectionDefinition然后用列表推导式functiontest_fn[step.name]把 JSON 中的每个步骤直接索引test_fn字典。只要有一个步骤名对不上键test_fn[step.name]就会抛KeyError整个测试连接直接失败——这正是校验器必须做此检查的原因。此外该函数还为整轮测试设置了默认 3 分钟超时timeout_secondsTHREE_MIN。步骤函数本身应无参数用functools.partial绑定、失败时抛异常、成功返回None。常见步骤命名约定数据库为CheckAccess、GetSchemas、GetTables、GetViews多库源加GetDatabases仪表盘为CheckAccess、GetDashboards、GetCharts管道为CheckAccess、GetPipelines消息为CheckAccess、GetTopics存储为CheckAccess、GetContainers。Check 4Registration——服务 Schema 枚举与 oneOf 注册检查连接器类型是否完成服务注册链路的两个后端入口详见 registration.mdserviceType 枚举在openmetadata-spec/src/main/resources/json/schema/entity/services/{serviceType}Service.json的serviceType枚举数组中加入连接器名enum: [..., MyDb]。connection oneOf在同一文件的config.oneOf数组中加入$ref指向连接 Schema{ $ref: ../../connections/{service_type}/{moduleName}Connection.json }。对全新连接器此项通常会输出[SKIP] Registration因为注册往往放在后续 PR 中完成——原文档示例也注明Not yet registered (expected for new connectors)。校验器应区分两种情况尚未注册可接受SKIP与已声明注册但引用断裂FAIL。若注册已进行还应连带核对完整链路ingestion/setup.py的 pip extras否则连接器在 Docker 镜像中缺少驱动、CLI workflow YAML 示例ingestion/src/metadata/examples/workflows/{name}.yaml、UI 侧{ServiceType}ServiceUtils.tsx的 Schema loader、ServiceIconUtils.ts的图标注册、public/locales/en-US/{ServiceType}/{Name}.md字段帮助文档以及BETA_SERVICES的 Beta 标记新连接器必须以 Beta 形态发布。Check 5Code Quality——四项静态检查规则最后对 Python 代码执行静态质量检查四项规则均出自 code_style.md无空except块禁止except: pass吞掉异常——错误必须携带上下文抛出如raise ValueError(fCannot connect to {config.hostPort}: {exc})以便日志可诊断。无import *禁用通配导入保持命名空间显式与可静态分析。函数签名带类型注解所有函数签名必须有类型注解可空字段用Optional[T]yield 方法用Iterable[Either[...]]导入自typing或collections.abc。这一条配合项目的ruff检查与 import 分层测试见 test_import_layers.py共同保障代码可维护性。使用ingestion_logger()而非logging.getLogger()连接器代码应从metadata.utils.logger导入ingestion_logger获取统一的日志器保证日志格式、分级与诊断流程如 ingestion-log-streaming 所描述的流式日志一致而不是各自创建裸 logger。其他常见的补充检查点还包括import 顺序stdlib → 第三方 → OpenMetadata 生成 → OpenMetadata 内部、Pydantic 模型在别名场景设置model_config ConfigDict(populate_by_nameTrue)、错误消息包含上下文信息等。输出格式PASS / FAIL / SKIP 清单语义校验完成后返回逐项清单每项为[PASS]/[FAIL]/[SKIP]加结论描述FAIL 项必须附带失败细节哪个文件、缺什么[PASS] Schema Validation — All fields correct [FAIL] Python Structure — Missing copyright header in client.py [PASS] Test Connection — 3/3 steps matched [SKIP] Registration — Not yet registered (expected for new connectors) [PASS] Code Quality — No issues found清单语义约定建议如下便于与人类 Reviewer 和 CI 流程对接[PASS]检查通过附简短证据如 3/3 steps matched、All fields correct[FAIL]存在阻断性问题必须附具体文件与缺失项如 Missing copyright header in client.py并给出修复指引[SKIP]合法跳过必须附原因如 Not yet registered (expected for new connectors)、No lineage capability declared避免把合理跳过误报为通过。在失败处理上校验器应遵循先 Schema、后代码的顺序Schema 是生成的唯一事实来源Schema 不合法会导致 Pydantic/Java 模型、UI 表单全部错位因此 Check 1 失败时Check 25 的结论只能作为参考信息不应被当成独立通过。修复后还需要重新生成派生代码并格式化make generatePython 模型、mvn clean install -pl openmetadata-specJava 模型、yarn parse-schemaUI Schema、make py_format/mvn spotless:apply格式化。落地建议把校验器嵌入开发与审查流程要让这套校验发挥最大价值可以把它接入以下环节脚手架后自检scripts/scaffold_connector.py生成连接器骨架后立即运行校验保证新代码从第一行起就符合结构约定。PR 预检在提交前对git diff涉及的source/{service_type}/{name}/路径批量执行 5 项检查作为轻量本地门禁替代人工逐文件核对。评审辅助与 connector-review 的analyze_connector.py脚本配合先用校验器给出确定性结论PASS/FAIL/SKIP再由 Reviewer 聚焦于设计层面的审查能力声明是否真实、测试是否覆盖真实行为等。回归基线对既有连接器定期运行捕获新改动破坏旧连接器的回归例如test_fn键被改名但测试连接 JSON 未同步、能力标志被误删等。需要说明的适用前提校验器是结构合规性检查它验证连接器是否符合 OpenMetadata 的工程标准但不能证明连接器功能正确——后者仍需单元测试ingestion/tests/unit/topology/{service_type}/test_{name}.py与集成测试ingestion/tests/integration/connections/test_{name}_connection.py使用 testcontainers来覆盖测试规范参见 testing.md。将结构校验与行为测试组合使用才能完整回答这个连接器能不能合入。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenMetadata Connector Validator 实战指南：用 5 项检查自动校验连接器实现是否符合标准
OpenMetadata Connector Validator 实战指南用 5 项检查自动校验连接器实现是否符合标准【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata本文以 OpenMetadata 仓库中的 Connector Validator Agent 定义 为核心完整讲解如何对一个连接器Connector实现执行 Schema、Python 结构、Test Connection、注册与代码质量五类自动化校验。读完本文你将掌握这套校验的每一条判定规则、底层依据与修复路径能够独立审查任意新增连接器如ingestion/src/metadata/ingestion/source/database/my_db/是否达到 OpenMetadata 的合入标准。校验器在连接器开发生命周期中的位置OpenMetadata 连接器采用schema-firstSchema 优先架构一份 JSON Schema 是唯一事实来源通过代码生成级联到 Python Pydantic 模型、Java 模型、TypeScript 类型、UI 配置表单、API 请求校验与测试夹具参见 main.md。因为绝不手写配置类Never hand-write config classes任何一处 Schema 或注册遗漏都会在运行期以难以定位的方式暴露——连接器不出现在 UI、渲染成默认图标、测试连接步骤找不到函数等。Connector Validator 正是针对这一痛点设计的一个校验代理validation agent给定一个连接器路径它按顺序执行 5 项确定性检查并输出[PASS]/[FAIL]/[SKIP]清单。它面向的场景包括新连接器脚手架生成后的自检PR 合入前对新增source/{service_type}/{name}/目录的审查评审 Agent 与人类 Reviewer 的辅助检查工具可参考同仓库的 connector-review SKILL 及其模板。Check 1Schema Validation——JSON Schema 的 5 个硬性字段第一步读取连接 Schema JSON 文件其标准位置为openmetadata-spec/src/main/resources/json/schema/entity/services/connections/{service_type}/{moduleName}Connection.json见 schema.md。校验项包括顶层字段完备$id完整 URI 路径、$schemahttp://json-schema.org/draft-07/schema#、titlePascalCase 连接名、javaType完整 Java 类路径、type: object、additionalProperties: false必须全部存在。additionalProperties: false用于阻止 UI/API 传入未声明字段是防止配置漂移的关键。definitions 类型枚举definitions块中必须有一个类型枚举如myDbType枚举值即服务类型名如MyDb并带default。该枚举值会被生成进{ServiceType}Type是 UI、ServiceSpec 解析与注册链路的公共标识。$ref路径可达性所有$ref指向的仓库文件必须真实存在。常见共享引用包括能力标志../connectionBasicType.json#/definitions/supportsMetadataExtraction、SSL 配置../../../../security/ssl/verifySSLConfig.json#/definitions/verifySSLConfig、过滤模式../../../../type/filterPattern.json#/definitions/filterPattern、认证./common/basicAuth.json等。校验器需逐一解析相对路径并确认目标文件存在可通过 Grep/Glob 完成。supportsMetadataExtraction必须存在该能力标志定义于 connectionBasicType.jsondefinitions.supportsMetadataExtraction是所有连接器的必备能力。此外按能力声明supportsUsageExtraction、supportsLineageExtraction、supportsProfiler、supportsDBTExtraction等。一份最小数据库连接 Schema 的结构如下完整模板见 schema.md{ $id: https://open-metadata.org/schema/entity/services/connections/database/myDbConnection.json, $schema: http://json-schema.org/draft-07/schema#, title: MyDbConnection, description: MyDb Connection Config, type: object, javaType: org.openmetadata.schema.services.connections.database.MyDbConnection, definitions: { myDbType: { description: Service type., type: string, enum: [MyDb], default: MyDb } }, properties: { type: { $ref: #/definitions/myDbType, default: MyDb }, hostPort: { title: Host and Port, type: string, format: uri }, supportsMetadataExtraction: { $ref: ../connectionBasicType.json#/definitions/supportsMetadataExtraction } }, additionalProperties: false, required: [hostPort] }required数组也有明确规则hostPort恒为必需采用认证的服务需把username/password或token/apiKey置为必需存在多种认证方式且无合理默认时authType应为必需。判定原则是——若省略某字段会在运行期抛出不透明的认证错误就应在 Schema 中将其设为required让 UI 前置校验。Check 2Python Structure——连接器目录的四件套与版权头每个连接器位于ingestion/src/metadata/ingestion/source/{service_type}/{name}/校验器检查以下内容必备文件齐全__init__.py模块标记、connection.py创建与测试连接、metadata.py元数据抽取、service_spec.py向框架注册连接器。非数据库连接器还应有client.py数据库连接器应有queries.py具备血缘/用量能力时还应有lineage.py、usage.py、query_parser.py见 main.md 的 Connector Anatomy 表。版权头所有.py文件必须以# Copyright 2025 OpenMetadata开头的版权头内容见 code_style.md。缺失版权头是最常见的 FAIL 项例如原文示例中的client.py。service_spec.py导出ServiceSpec变量变量名必须精确为ServiceSpec大小写敏感模块名必须是service_spec.py。框架在metadata.ingestion.source.{service_type}.{name}.service_spec.ServiceSpec处动态解析它。数据库连接器用DefaultDatabaseSpec(metadata_source_class..., connection_class..., lineage_source_class..., usage_source_class...)其中DefaultDatabaseSpec会自动装配 profiler/sampler/test suite非数据库连接器用BaseSpec(metadata_source_class...)详见 service_spec.md。metadata.py含create()类方法源码类如MyDbSource通过create()完成从配置到实例的构造是拓扑处理器topology processor入口必须存在。Check 3Test Connection——步骤名与test_fn键的严格对齐读取测试连接 JSON 文件位置openmetadata-service/src/main/resources/json/data/testConnections/{service_type}/{moduleName}.json验证其中每个步骤的name都能在connection.py的test_fn字典中找到同名键。测试连接 JSON 的标准形态{ name: MyDb, displayName: MyDb Test Connection, description: Validate that we can connect and extract metadata from MyDb., steps: [ { name: CheckAccess, description: Validate access to the service, errorMessage: Failed to connect to MyDb, mandatory: true, shortCircuit: true }, { name: GetDatabases, description: List available databases, errorMessage: Failed to list databases, mandatory: true, shortCircuit: false } ] }在connection.py中test_connection()构造test_fn字典时键必须与上述name逐字精确匹配见 connection.mddef test_connection(metadata, client, service_connection, automation_workflowNone) - None: test_fn { CheckAccess: partial(test_access, client), GetDatabases: partial(test_list_databases, client), } test_connection_steps( metadatametadata, test_fntest_fn, service_typeservice_connection.type.value, automation_workflowautomation_workflow, )为什么必须严格对齐可以看底层实现 test_connections.py 的test_connection_steps()它先从服务端按service_type .testConnectionDefinition拉取TestConnectionDefinition然后用列表推导式functiontest_fn[step.name]把 JSON 中的每个步骤直接索引test_fn字典。只要有一个步骤名对不上键test_fn[step.name]就会抛KeyError整个测试连接直接失败——这正是校验器必须做此检查的原因。此外该函数还为整轮测试设置了默认 3 分钟超时timeout_secondsTHREE_MIN。步骤函数本身应无参数用functools.partial绑定、失败时抛异常、成功返回None。常见步骤命名约定数据库为CheckAccess、GetSchemas、GetTables、GetViews多库源加GetDatabases仪表盘为CheckAccess、GetDashboards、GetCharts管道为CheckAccess、GetPipelines消息为CheckAccess、GetTopics存储为CheckAccess、GetContainers。Check 4Registration——服务 Schema 枚举与 oneOf 注册检查连接器类型是否完成服务注册链路的两个后端入口详见 registration.mdserviceType 枚举在openmetadata-spec/src/main/resources/json/schema/entity/services/{serviceType}Service.json的serviceType枚举数组中加入连接器名enum: [..., MyDb]。connection oneOf在同一文件的config.oneOf数组中加入$ref指向连接 Schema{ $ref: ../../connections/{service_type}/{moduleName}Connection.json }。对全新连接器此项通常会输出[SKIP] Registration因为注册往往放在后续 PR 中完成——原文档示例也注明Not yet registered (expected for new connectors)。校验器应区分两种情况尚未注册可接受SKIP与已声明注册但引用断裂FAIL。若注册已进行还应连带核对完整链路ingestion/setup.py的 pip extras否则连接器在 Docker 镜像中缺少驱动、CLI workflow YAML 示例ingestion/src/metadata/examples/workflows/{name}.yaml、UI 侧{ServiceType}ServiceUtils.tsx的 Schema loader、ServiceIconUtils.ts的图标注册、public/locales/en-US/{ServiceType}/{Name}.md字段帮助文档以及BETA_SERVICES的 Beta 标记新连接器必须以 Beta 形态发布。Check 5Code Quality——四项静态检查规则最后对 Python 代码执行静态质量检查四项规则均出自 code_style.md无空except块禁止except: pass吞掉异常——错误必须携带上下文抛出如raise ValueError(fCannot connect to {config.hostPort}: {exc})以便日志可诊断。无import *禁用通配导入保持命名空间显式与可静态分析。函数签名带类型注解所有函数签名必须有类型注解可空字段用Optional[T]yield 方法用Iterable[Either[...]]导入自typing或collections.abc。这一条配合项目的ruff检查与 import 分层测试见 test_import_layers.py共同保障代码可维护性。使用ingestion_logger()而非logging.getLogger()连接器代码应从metadata.utils.logger导入ingestion_logger获取统一的日志器保证日志格式、分级与诊断流程如 ingestion-log-streaming 所描述的流式日志一致而不是各自创建裸 logger。其他常见的补充检查点还包括import 顺序stdlib → 第三方 → OpenMetadata 生成 → OpenMetadata 内部、Pydantic 模型在别名场景设置model_config ConfigDict(populate_by_nameTrue)、错误消息包含上下文信息等。输出格式PASS / FAIL / SKIP 清单语义校验完成后返回逐项清单每项为[PASS]/[FAIL]/[SKIP]加结论描述FAIL 项必须附带失败细节哪个文件、缺什么[PASS] Schema Validation — All fields correct [FAIL] Python Structure — Missing copyright header in client.py [PASS] Test Connection — 3/3 steps matched [SKIP] Registration — Not yet registered (expected for new connectors) [PASS] Code Quality — No issues found清单语义约定建议如下便于与人类 Reviewer 和 CI 流程对接[PASS]检查通过附简短证据如 3/3 steps matched、All fields correct[FAIL]存在阻断性问题必须附具体文件与缺失项如 Missing copyright header in client.py并给出修复指引[SKIP]合法跳过必须附原因如 Not yet registered (expected for new connectors)、No lineage capability declared避免把合理跳过误报为通过。在失败处理上校验器应遵循先 Schema、后代码的顺序Schema 是生成的唯一事实来源Schema 不合法会导致 Pydantic/Java 模型、UI 表单全部错位因此 Check 1 失败时Check 25 的结论只能作为参考信息不应被当成独立通过。修复后还需要重新生成派生代码并格式化make generatePython 模型、mvn clean install -pl openmetadata-specJava 模型、yarn parse-schemaUI Schema、make py_format/mvn spotless:apply格式化。落地建议把校验器嵌入开发与审查流程要让这套校验发挥最大价值可以把它接入以下环节脚手架后自检scripts/scaffold_connector.py生成连接器骨架后立即运行校验保证新代码从第一行起就符合结构约定。PR 预检在提交前对git diff涉及的source/{service_type}/{name}/路径批量执行 5 项检查作为轻量本地门禁替代人工逐文件核对。评审辅助与 connector-review 的analyze_connector.py脚本配合先用校验器给出确定性结论PASS/FAIL/SKIP再由 Reviewer 聚焦于设计层面的审查能力声明是否真实、测试是否覆盖真实行为等。回归基线对既有连接器定期运行捕获新改动破坏旧连接器的回归例如test_fn键被改名但测试连接 JSON 未同步、能力标志被误删等。需要说明的适用前提校验器是结构合规性检查它验证连接器是否符合 OpenMetadata 的工程标准但不能证明连接器功能正确——后者仍需单元测试ingestion/tests/unit/topology/{service_type}/test_{name}.py与集成测试ingestion/tests/integration/connections/test_{name}_connection.py使用 testcontainers来覆盖测试规范参见 testing.md。将结构校验与行为测试组合使用才能完整回答这个连接器能不能合入。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考