如果在Java Maven项目中使用了某个jar，是否有办法使Jenkins的构建失败？
例如，我知道org.example：badartifact：1.0.1有一个安全漏洞。我告诉了所有人，他们修复了他们的项目...，但是也许一些第三方工件将它们作为传递对象而带给了他们，但没人意识到这一点。
或者也许有人忘记了这个旧错误...
因此，我希望最好在Jenkins中进行最后一次检查，以免我们最终不包含包含该特殊工件的项目。
您如何处理这种情况，您使用什么工具？（将库列入白名单？将库列入黑名单？等）
任何建议表示赞赏。
可能的Maven解决方案
您可以拥有一个公司超级POM（公司/部门/团队内所有Maven项目的父POM），并在该超级POM中配置Maven Enforcer插件（其bannedDependencies规则）以禁止任何库，版本甚至范围。我亲自使用了这个选项，即使是发生了一些小错误（例如，不在测试范围内的junit都会使构建失败）。
此解决方案是集中式解决方案，因此易于维护，但是要求所有项目都具有相同的父POM，并且开发人员可以随时更改父pom，因此可以跳过此管理。另一方面，集中式父POM对于依赖项管理，通用配置文件，报告等非常有用。
注意：例如，您不能通过默认的活动配置文件在Jenkins服务器的Maven设置中对其进行配置，例如，以便将其应用于所有正在运行的Maven构建，因为Maven限制了设置所提供的配置文件中对构建的自定义（设计选择，以限制外部影响，从而使故障排除更加容易）。我过去曾尝试过并碰壁。
外部文件中的配置文件
从严格意义上讲，在外部文件（即settings.xml或profiles.xml）中指定的配置文件是不可移植的。似乎很有可能更改构建结果的任何内容都限于POM中的内联配置文件。诸如存储库列表之类的东西可能只是经过批准的工件的专有存储库，而不会改变构建的结果。因此，您将只能修改和部分，以及一个额外的部分
可能的Jenkins解决方案
如果您想直接在Jenkins中集中管理，因此要独立于Maven构建，我过去已经应用了以下这些解决方案（它们非常有效）：
mvn dependency:tree，因此将依赖项列表（甚至是传递性）作为构建输出的一部分。然后，与您的禁止依赖项匹配的Text Finder规则将与之匹配，并使构建失败。本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句