通过拉取请求发布集成

当您的集成完成时，是时候发起一个 PR 将其包含在集成仓库中了。在发起 PR 之前，请确保您已完成以下事项：

1. 运行提交前检查 运行 elastic-package check 以验证格式、构建和 linting。如果文件需要重新格式化，请运行 elastic-package format。

2. 添加变更日志条目 包含一个指向您 PR 的 link: 字段。使用正确的类型：enhancement（增强）、bugfix（错误修复）或 breaking-change（中断性变更）。

3. 更新 CODEOWNERS（仅限新集成）将您的包添加到 .github/CODEOWNERS，格式如下：/packages/<package_name> @elastic/<team-name>。

4. 包含测试覆盖率 在提交之前运行 elastic-package test。使用 elastic-package test system --generate 生成 sample_event.json。

5. 适当升级软件包版本 对于向后兼容的错误修复和仅文档更改，使用补丁版本升级（patch version）。对于向后兼容的新功能，使用次要版本升级（minor version）。

6. 记录中断性变更 在变更日志中使用 breaking-change 类型，并清晰地描述对现有用户的影响。中断性变更需要进行主版本升级（major version bump）。

   以下变更被视为中断性变更：

   • 字段类型变更：更改字段的数据类型（例如，将 keyword 更改为 long，或将 long 更改为 keyword）会导致现有用户的映射冲突
   • 字段删除：删除用户可能在仪表板、警报或查询中依赖的字段
   • 字段重命名：重命名字段会破坏现有引用（仪表板、已保存查询、检测规则）
   • ECS 字段冲突：从 ECS 命名空间中删除非 ECS 字段或更改 ECS 字段映射
   • 事件值变更：更改标准化值（例如，将 event.outcome 从 "Succeeded" 更改为 "success"）
   • 配置变更：需要新的凭据、更改身份验证方法或修改必需设置
   • 数据流变更：拆分、合并或重构数据流
   • 转换目标变更：修改转换（transform）的目标索引（需要更新 fleet_transform_version）
   • 默认行为变更：更改会改变数据采集的默认设置（例如，去重设置、数据流数据集）

   最大限度地降低中断性变更带来的风险

   中断性变更可能会影响此仓库内外的相关内容。在引入中断性变更之前：

   • 在此仓库中搜索依赖内容：使用 grep 或搜索工具查找引用您正在更改的字段的仪表板、转换和其他资产。
   • 检查 security_detection_engine 包：安全检测规则可能依赖于您的集成字段。在 packages/security_detection_engine/ 中搜索受影响字段的引用。
   • 与其他团队协调：其他 Elastic 仓库（例如 detection-rules、kibana）可能包含依赖于您集成字段的内容。在合并中断性变更之前，请联系相关团队。
   • 优先考虑弃用：与其立即删除或重命名字段，不如考虑设置一个弃用期，在此期间同时填充旧字段和新字段，从而给用户留出迁移时间。
   • 更新依赖资产：如果此仓库中的仪表板或其他资产引用了已更改的字段，请在同一个 PR 中更新它们或协调这些变更。

7. 向摄取管道添加错误处理 在处理器上包含 tag 字段并使用 on_failure 处理程序。遵循使用 _ingest.on_failure_* 字段的标准错误消息格式。

8. 撰写清晰的 PR 标题和描述 使用简洁、具有描述性的标题（例如 [New Integration] Add Acme Logs integration）。总结变更，参考相关议题（issues），并确保文档是最新的。

当 CI 通过时，将您的 PR 合并到集成仓库中。

一旦包含新版本包的 PR 被合并，就会触发所需的 CI 管道，将该新版本发布到 Package Storage V2，并使其在 https://epr.elastic.co 上可用。