我们有一个存储在磁盘上的计算数据缓存。我们想知道该计算数据是来自此版本还是来自不同版本的构建。目前，我们使用存储在MANIFEST.MF中的commit + timestamp作为识别构建的相对独特的方式。但是，时间戳会导致gradle中的增量构建问题，因为gradle知道时间已更改，重新生成MANIFEST.MF，并重新判断jar，即使没有其他更改。
我们希望将时间戳替换为更好的＆＃39; buildId＆＃39;进入MANIFEST.MF。要求是：
我认为正确的解决方案是使用实际依赖关系的哈希到＆＃39; jar＆＃39;任务，这是＆＃39; classes＆＃39;，这是将包含在jar中的所有已编译的类文件。
我可以，理论上，创建一个任务，它接受所有类的哈希，并将其注入清单。
但是，Gradle已经这样做了，这就是它如何确定任务是否是最新的。它需要输入的哈希值和输出的哈希值，并检查该组合是否在其数据库中。那么，有没有办法使用一些罕见的Gradle API或使用反射来访问这些信息？
或许还有其他一些解决方案？
答案 0 :(得分：2)
我认为您可能想要退回并重新评估您希望通过添加到清单文件中的buildIds实现的目标。具体来说，关于构建在开发机器上的第一个要求没有多大意义。您通常希望将某种buildIds添加到清单文件的原因是，您可以跟踪jar的构建位置和时间，以便您可以确定哪些源代码可以在出现问题时查看。如果您基于开发文件系统的内容生成构建，那么您将永远无法返回并确定构建的来源。如果buildId基于生成的类文件，甚至是开发人员机器上的源文件本身，那么开发人员所要做的就是更改单个文件中的单个字符，并且该构建永远消失，无法重新生成除非该开发人员可以执行撤消操作，将文件系统恢复到原来的形状。
相反，您应该将buildIds建立在可以重新创建的东西上，而无需开发人员记住任何内容。为了实现这一点，buildIds必须既可搜索又随时可供团队的所有成员使用。修订控制提交满足所有这些要求，并且通过它的声音，您已经使用了这些要求，因此没有额外的开销将其添加到您的工作流程中。
我建议忘记基于buildIds 关于文件系统的内容，并以提交为基础。如果您担心开发人员能够生成不来自master / trunk / etc的构建，则所有主要版本控制系统都会为分支创建提供一些方法，这仍然允许开发人员检查不会干扰的代码。初级生产。如果您使用修订号/哈希来跟踪jar的版本，那么您可以回过头来重新构建构建，即使它只是来自开发人员计算机上的本地分支。我不推荐使用本地分支的最后一点，除非你知道构建将非常短暂，但是，因为团队中的任何其他人都无法搜索基于单个开发者机器本地分支的buildIds。相反，如果您使用的是分布式版本控制系统，我建议您将构建中使用的任何更改推送到中心位置，以便可能在构建中遇到问题的任何其他人都可以访问用于它的代码。
答案 1 :(得分：0)
您可以创建一个生成构建ID的任务，并使用类作为输入，输出是具有构建ID的文件。
构建ID不必是输入的哈希值，但可以只是一个时间戳。
但是，由于生成构建标识的任务取决于类，因此只有在发生更改时才会重新生成构建标识时间戳。