java - 如何将确定的唯一 buildId 注入(inject) Gradle 的 java jar list ？

Question

我们有一个存储在磁盘上的计算数据缓存。我们想知道计算出的数据是来自这个版本还是来自不同版本的构建。目前我们使用存储在 MANIFEST.MF 中的提交 + 时间戳作为识别构建的相对独特的方式。然而，时间戳会导致 gradle 中的增量构建问题，因为 gradle 知道时间已经改变，重新生成 MANIFEST.MF，并重新打包 jar，即使没有其他任何改变。

我们想在 MANIFEST.MF 中用更好的“buildId”替换时间戳。要求是:

• 对于不同的构建是唯一的:仅仅提交是不够的，因为在开发机器上可能有未提交的更改
• 确定性:时间戳不起作用，因为 Gradle 会将其视为依赖项中的“更改”，即使其他依赖项未更改也会重建 jar

我认为正确的解决方案是使用“jar”任务的实际依赖项的散列，即“classes”，即所有将包含在 jar 中的已编译类文件。

理论上，我可以创建一个任务，它获取所有类的哈希值，并将其注入(inject)到 list 中。

但是，Gradle 已经这样做了，这就是它确定任务是否最新的方式。它采用输入的散列和输出的散列，并检查该组合是否在其数据库中。那么，有没有办法使用一些罕见的 Gradle API 或使用反射来访问这些信息？

或者也许还有其他解决方案？

Answer 1

我想您可能想退后一步，重新评估您希望通过添加到 list 文件中的 buildId 实现的目标。具体来说，您所说的第一个要求，关于在开发机器上构建，没有多大意义。您通常希望将某种 buildId 添加到 list 文件的原因是，您可以跟踪构建 jar 的位置和时间，以便您可以确定要查看哪组源代码并在出现问题时查看。如果您根据开发人员文件系统的内容生成构建，您将永远无法返回并确定该构建的来源。如果 buildId 基于生成的类文件，甚至是开发人员机器上的源文件本身，那么开发人员所要做的就是更改单个文件中的单个字符，而该构建将永远消失，无法重新生成除非该开发人员可以执行撤消操作，将文件系统恢复到原来的状态。

相反，您应该将您的 buildId 建立在不需要开发人员记住任何东西的情况下可以重新创建的东西上。为了实现这一点，buildId 需要随时可供团队的所有成员搜索和使用。修订控制提交满足所有这些要求，并且听上去是您已经在使用的内容，因此无需额外开销即可将其添加到您的工作流程中。

我建议忘记基于你的 buildIds基于文件系统的内容并将其基于提交。如果您担心开发人员能够生成不是来自 master/trunk/etc 的构建，所有主要的修订控制系统都提供了一些创建分支的方法，这仍然允许开发人员 checkin 不会干扰的代码初级生产构建。如果您使用修订号/哈希来跟踪 jar 的版本，那么您就可以返回并准确地重现构建，即使它只是来自开发人员机器上的本地分支。我不建议最后一点关于使用本地分支，除非你知道构建将非常短暂，但是，因为基于单个开发机器本地分支的 buildIds 不能被团队中的任何其他人搜索。相反，如果您使用的是分布式版本控制系统，我建议您将构建中使用的任何更改推送到一个中央位置，以便任何其他可能遇到构建问题的人都可以访问用于它的代码。