鉴于:
如何优化我们的构建,以便在运行PMD时,它仅针对自上次绿色构建以来已修改的文件运行。
备份...我们的PMD需要3-4分钟才能运行~150万行代码,如果发现问题,报告在完成之前总会耗尽内存。我希望减少建设时间的几分钟,并获得关于故障的良好报告。我原来的方法是我:
比我想要的更复杂,但值得拥有更快但仍然可靠的构建。
一旦我意识到Jenkins不会轻易地给我我想要的东西,我意识到还有另一种可能的方法。我们标记每个绿色构建。我可以简单地获取自标签以来更改的文件列表,然后我可以完全取消pmd_failures.txt。
没有骰子。自从Perforce标签xxxx以来,获取文件列表的想法似乎从未被简化过:
$ p4 files //path/to/branch/...@label > label.out $ p4 files //path/to/branch/...@now > now.out $ diff label.out now.out
令人讨厌,但更重要的是,对于我们成千上万的文件来说,比简单地运行PMD更慢。
所以现在我正在尝试与其他构建内容并行运行PMD,这仍然是浪费时间和资源并使我们的构建更复杂。在我看来,我无法从Jenkins或Perforce轻松获取已更改文件的列表。有没有其他人找到这些问题的合理解决方法?
答案 0 :(得分:4)
我想我找到了答案,如果有效,我会将答案标记为正确。
它比我想要的要复杂一点,但我认为值得保存3-4分钟(以及潜在的内存问题)。
$ p4 counter last_green_trunk_cl %P4_CHANGELIST%
last.green.cl
并获取以下文件的列表:$ p4 files //path/to/my/branch/...@${last.green.cl},now //path/to/my/branch/myfile.txt#123 - edit change 123456 (text) //path/to/my/branch/myotherfile.txt#123 - add change 123457 (text) etc... (have to parse the output)
这样我们就不需要pmd_failures.txt了,我们只针对自上次绿色构建以来发生过变化的文件运行PMD。
[编辑:将其更改为使用p4计数器,这比检入文件更快。此外,这非常成功,所以我将其标记为已回答]
答案 1 :(得分:1)
我不是百分百肯定,因为我从不在Perkins中使用Perforce,但我相信Perforce会通过环境变量$P4_CHANGELIST
传递更改列表编号。有了它,您可以运行p4 filelog -c $P4_CHANGELIST
,它应该为您提供该特定更改列表中的文件。从那里开始,编写一些东西并不难以获得更改的文件(加上旧的故障进入PMD)。
我很久没有使用Perforce,但我相信-Ztag
参数可以更轻松地解析各种脚本语言的P4输出。
答案 2 :(得分:1)
您是否考虑过使用自动标签?它们基本上只是更改列表编号的别名,因此更容易获得两个自动标签之间不同的文件集。