[elastic/elasticsearch]生成测试依赖项文件以支持权利中的单元测试

生成具有以下信息和格式的测试文件：

{ "component": "<component name>", "locations": [ { "representative_class": <class name with package>, "module": "<module name>" }, ... ] }

无痛：

{ "component": "lang-painless", "locations": [ { "representative_class": "org/objectweb/asm/tree/analysis/Analyzer.class", "module": "org.objectweb.asm.tree.analysis" }, ... ] }

然后它将以下文件复制到 jar 中以供单元测试使用：

* META-INF/test-build-info.json * META-INF/es-plugins/<plugin name>/plugin-descriptor.properties * META-INF/es-plugins/<plugin name>/entitlement-policy.yaml

对于服务器来说，jar 中的文件变成如下形式：

* META-INF/test-build-info.json

这应该提供足够的信息，以便BootstrapForTesting能够构建调用者类到策略文件的映射，使用类文件在类路径中查找 jar 或目录，然后将其与其指定的模块关联，最后使用指定的模块查找相应的授权策略。caller class -> specified module -> entitlement policy

jdconrad

正在 ping @elastic/es-core-infra (Team:Core/Infra)

elasticsearchmachine

我们可以通过仅将包名映射到模块，而不是将每个类都映射到模块，来减少冗余。这样应该可以大大减小文件大小。

prdoyle

杰克指出，每个 jar/目录已经只有一个条目了。

在这种情况下，我想知道是否应该在结构中包含 jar 包/目录信息，即使只是为了排查问题。即使我们的用例不需要它，如果文件中包含 jar 包/目录信息，对用户来说也会更方便。

更新：之所以使用代表性类而不是 jar 包/目录，是因为其位置在运行时可能会因运行的测试不同而有所变化。如果我们不小心，这些信息不仅可能毫无用处，还可能产生误导。

prdoyle

需要注意的是：通过“扁平化”描述符，META-INF/es-plugins/<plugin name>/plugin-descriptor.properties我们失去了“外部”插件和模块之间的区别。我们可以做两件事：

忽略这一点，并假设一切都是“内部的”：这仅仅意味着插件可以请求一些额外的权限，而你不会在单元测试中发现这一点（但它会在任何 IT 测试甚至冒烟测试中失败——ES 将拒绝启动）。将内容移动到 2 个不同的位置，META-INF/es-modules/<plugin name>/plugin-descriptor.properties（用于外部）和`META-INF/es-plugins/<plugin name>/plugin-descriptor.properties（用于内部/模块）。

在https://github.com/elastic/elasticsearch/pull/127814中，我目前选择 1，但我想在这里澄清一下。

ldematte

将它们全部视为内部测试用例似乎没问题。我们可以（单独）添加一个任务来“验证”插件的授权策略，该任务会启动一个 JVM 来解析它（JVM 会知道它是模块还是插件）。

rjernst

为什么选择 1 而不是 2？

乍一看，我认为让测试环境和生产环境中的检查行为保持一致，比让它们行为不同，然后再通过额外的验证来弥补这种差异要好得多。

prdoyle

@ryan @ldematte @mark-vieira Patrick 和我相信这已经准备好进行新一轮审核了。谢谢！

jdconrad

[elastic/elasticsearch]生成测试依赖项文件以支持权利中的单元测试

回答