正在加载

发布支持旧软件包版本的错误修复

在某些情况下，当我们停止支持旧版本的堆栈后，发现需要为一些旧软件包版本添加错误修复时，我们必须进行一些手动更改才能向用户发布该错误修复。 例如：在此 PR (AWS 软件包版本 1.23.4) 中，对 Kibana 版本 7.x 的支持已删除，并将 AWS 软件包版本从 1.19.5 提升到 1.20.0。 但我们发现 EC2 仪表板中存在一个错误，需要使用 Kibana 版本 7.x 进行修复。 因此，我们不需要添加新的 AWS 软件包版本 1.23.5，而需要在 1.19.5 和 1.20.0 之间进行修复。

请按照以下详细步骤发布给定软件包版本的修复程序

  1. 查找需要修复的 git 提交（软件包版本）

    在上面的示例中，要修复的提交是在此 PR 更新软件包 aws 之前的提交。

    • 使用网页

    • 使用命令行

      cd packages/<package_name>
git log --grep "#<pr_id>" .
git log -n 1 <merge_commit>^ .

# following the example
$ cd packages/aws
$ git log --grep "#3688"
commit aa63e1f6a61d2a017e1f88af2735db129cc68e0c
Author: Joe Reuter <xx@email.de>
Date:   Mon Aug 8 17:14:55 2022 +0200

    Inline all aws dashboards (#3688)

    * inline all aws dashboards

    * format

    * apply the right format

    * inline again

    * format
$ git log -n 1 aa63e1f6a61d2a017e1f88af2735db129cc68e0c^ .
commit 8cb321075afb9b77ea965e1373a03a603d9c9796
Author: Mario Castro <xx@gmail.com>
Date:   Thu Aug 4 16:52:06 2022 +0200

    Move lightweight manifest to integration for EBS data stream (#3856)

  2. 运行 integrations-backport 管道 https://buildkite.com/elastic/integrations-backport 以创建向后移植分支。 buildkite buid

    请注意！，如果您只是运行管道，它将等待您的输入，没有输入将不会发生任何事情。

    waiting input step

    管道的输入

    • DRY_RUN (默认值: "true")，如果 DRY_RUN 定义为 "true"，它将检查

      • 软件包是否已发布，
      • 输入的提交是否存在，
      • 向后移植分支是否存在。 此外，它将创建本地分支，使用 .buildkite 和 .ci 文件夹更新分支，并删除除已定义软件包之外的其他软件包（如果设置为输入）。 在此模式下，此本地分支不会推送到上游存储库。

    如果 DRY_RUN 定义为 "false"，除了上面写的内容之外，它还将创建一个提交并将本地分支推送到上游存储库 https://github.com/elastic/integrations.git。 在这种情况下，分支的名称将为 +backport-${PACKAGE_NAME}-${TRIMMED_PACKAGE_VERSION}+，例如，backport-aws-1.19。

    • BASE_COMMIT (默认值: "") - 输入上一步的提交 (8cb321075afb9b77ea965e1373a03a603d9c9796)
    • PACKAGE_NAME (默认值: "") - 输入软件包名称，例如 aws
    • PACKAGE_VERSION (默认值: "") - 输入软件包版本，例如：1.19.7, 1.0.0-beta1
    • REMOVE_OTHER_PACKAGES (默认值: "false") 如果 REMOVE_OTHER_PACKAGES 定义为 "true"，则除了已定义的软件包之外，所有来自 packages 文件夹的软件包都将从创建的分支中删除。

  3. 为错误修复创建一个 PR

    在您自己的远程创建一个新分支（建议不要使用以 backport- 开头的分支名称），并在其中应用错误修复。 记住更新软件包清单中的版本（更新补丁版本，如 1.19.<x+1>），并为该补丁版本添加新的变更日志条目。

    准备就绪后，打开一个 PR，选择上面创建的分支作为基础分支：backport-<package_name>-<package_major_version>.<package_minor_version> (例如 backport-aws-1.19)。

    一旦此 PR 合并，此软件包的新版本将按照通常的 CI/CD 作业自动发布。

    如果需要为该版本发布新的修复程序，则无需创建新分支。 只需创建一个新的 PR，将一个新分支合并到先前创建的同一向后移植分支上即可。

  4. 更新 main 中的变更日志

    一旦 PR 已合并到相应的向后移植分支（例如 backport-aws-1.9）并且软件包已发布，则应手动创建一个新的拉取请求以更新 main 分支中的变更日志，以包含在向后移植分支中发布的新版本。 请注意，按照版本顺序添加变更日志条目。

    为了保持跟踪，这个新的 PR 应该在其描述中引用 (relates) 向后移植 PR。

  5. 已知问题及其解决方案

    1. 缺少 shellinit 命令

    2. 未找到许可证文件

© . All rights reserved.