加载中

CI 指标

除了运行我们的测试之外，CI 还收集有关 Kibana 构建的指标。这些指标会发送到一个外部服务，以跟踪随时间的变化，并为 PR 作者提供对其更改影响的洞察。

这些指标有助于贡献者了解他们对 Kibana 创建的捆绑包大小的影响，并帮助确保 Kibana 的加载速度尽可能快。

页面加载捆绑包大小

每个捆绑包/插件生成的入口文件的大小。此文件始终在每次页面加载时加载，因此它应该尽可能小。要减小此指标，您可以将所有并非在每次页面加载时都必需的代码置于 async import() 之后。

与其它插件静态共享的代码将计入该插件的 页面加载捆绑包大小。这包括来自 public/index.ts 文件以及 extraPublicDirs manifest 属性引用的任何文件的导出。

异步块大小
为每个 async import() 语句导入的文件创建一个“异步块”。此指标跟踪这些块的总大小（以字节为单位），按插件/捆绑包 ID 分类。您可以将其视为用户访问捆绑包中的所有组件/应用程序时需要下载的代码量。
杂项资产大小
“杂项资产”是指任何非异步块或入口块的内容，通常是图像。此指标跟踪这些资产的总大小（以字节为单位），按插件/捆绑包 ID 分类。
@kbn/optimizer 捆绑包模块计数
每个捆绑包/插件中包含的独立模块数量。这是我们了解特定捆绑包由 @kbn/optimizer 构建所需时间的最佳指标，因此我们报告它以帮助人们了解何时导入了可能包含意外数量子模块的模块。

Kibana 可分发包的大小是一项重要指标，因为它不仅影响下载时间，还影响下载后解压所需的时间。

我们不针对 PR 报告某些指标，因为 gzip 压缩在提供相同输入时会产生不同的文件大小，因此即使 PR 作者没有进行任何相关更改，此指标也会定期显示更改。

所有指标均从为 Linux 平台生成的 tar.gz 存档中收集。

可分发文件计数
默认可分发包中包含的文件数量。
可分发大小
默认可分发包的大小（以字节为单位）。（不针对 PR 报告）

Elasticsearch 默认将索引中的字段数限制为 1000，我们希望避免提高此限制。

已保存对象 .kibana 字段计数
按已保存对象类型细分的已保存对象字段数量。

您可以使用 @kbn/dev-utils 包提供的 CiStatsReporter 类报告新指标。此类在 CI 上自动配置，在 CI 之外运行时其方法无操作。有关更多详细信息，请查看 CiStatsReporter README。

为了防止页面加载捆绑包变得异常大，我们限制了每个插件的 页面加载资产大小 指标。当 PR 将此指标提高到超出 limits.yml 中为该插件定义的限制时，提交状态将失败，PR 作者需要在 PR 合并之前决定如何解决此问题。

在大多数情况下，限制应该足够高，以至于 PR 不会触发超限，但当它们发生时，请确保通过尝试以下方法来清楚地说明超限的原因：

  1. 使用 --profile 标志在本地运行优化器，以生成 webpack stats.json 文件，这些文件可以使用许多不同的在线工具进行检查。重点关注名为 {{pluginId}}.plugin.js 的块； *.chunk.js 块构成了 异步块大小 指标，该指标当前没有限制，也是我们 减小页面加载块大小 的主要方式。

    node scripts/build_kibana_platform_plugins --focus {pluginid} --profile
# builds and creates {pluginDir}target/public/stats.json files for {pluginId} and any plugin it depends on

  2. 您可能还想为 PR 的上游分支创建统计信息，然后将它们并排比较在 Webpack 可视化工具中，以找出大小差异所在（使用两个浏览器标签页）。

  3. 对于相对较小的更改，您可能可以通过将两个不同分支的 stats.json 文件放入 Beyond Compare 来更好地理解问题

  4. 如果 Beyond Compare 中的更改过多，您可以使用 jq 将 stats.json 文件缩减为仅包含排序后的模块 ID 列表。

    jq -r .modules[].id {pluginDir}/target/public/stats.json | sort - > moduleids.txt

    为您的分支和 master 分支生成一个 moduleids.txt 文件，然后将它们放入 Beyond Compare 中，以获得对新内容的非常具体的视图。

  5. 作为最后的手段，您可能需要尝试直接比较捆绑包源代码。通常最好使用生产源代码进行此操作，以便您检查 CI 正在看到的实际字节变化。在构建完捆绑包的可分发版本后，使用 prettier 进行格式化，然后将其与来自上游的块一起放入 Beyond Compare 中。

    node scripts/build_kibana_platform_plugins --focus {pluginId} --dist
npm install -g prettier
prettier -w {pluginDir}/target/public/{pluginId}.plugin.js
# repeat these steps for upstream and then compare the two {pluginId}.plugin.js files in Beyond Compare

  6. 如果所有方法都失败了，请联系运营团队寻求帮助。

一旦您识别出已添加到构建的文件，您很可能只需要将它们置于异步导入之后，如 插件性能 中所述。

如果捆绑包大小没有因任何明显原因而膨胀，但仍然大于限制，您可以在 PR 中提高限制。可以通过手动编辑 limits.yml 文件 来实现，或者通过运行以下命令将限制更新到当前大小 + 15kb：

node scripts/build_kibana_platform_plugins --focus {pluginId} --update-limits

此命令必须在可分发模式下运行优化器，因此需要更长的时间，并为您的每台 CPU 启动一个工作进程。

对 limits.yml 文件 的更改将触发运营团队的审查，他们将尝试验证大小增加是否合理。如果您有从上述步骤中获得的发现，那将非常有帮助！

在尝试查找可减小捆绑包大小的更改时，请尝试在本地运行以下命令：

node scripts/build_kibana_platform_plugins --dist --watch --focus {pluginId}

这将构建您的插件以及您的插件所依赖的插件的前端捆绑包。每当您进行更改时，捆绑包都会重新构建，您可以在插件内的 target/public/metrics.json 文件中检查该构建的指标。当您保存源更改时，此文件将更新，有助于确定您的更改是否足够降低 页面加载资产大小。

如果您只想运行一次构建，可以运行：

node scripts/build_kibana_platform_plugins --validate-limits --focus {pluginId}

此命令需要应用生产优化以获得正确的尺寸，这意味着优化器将花费更长的时间运行，并且在大多数开发人员机器上将消耗所有机器资源 20 分钟或更长时间。如果您想在此过程中进行多任务处理，可能需要使用 --max-workers 标志限制工作进程的数量。

© . This site is unofficial and not affiliated with Elasticsearch BV.