我目前正在使用jenkins在预期的发布条件下部署应用程序，并且我被迫以root用户身份在已部署的系统上运行JUnit测试（因为应用程序具有仅可由root用户访问的某些文件） 。
我没有使用“调用ant”构建步骤来运行测试，而是使用sudo从“执行shell”构建步骤运行ant，类似于......
sudo ant -file build.xml -D.... test
因为jenkins用户具有执行此操作的必要root权限，但不能访问上述文件。
我意识到这样做会在工作空间中创建一些具有错误权限的文件夹，但我在“执行shell”后更正了这一点。
一切似乎都很好，但感觉就像是一种解决方法。
我的问题是，与构建步骤“调用ant”相比，以这种方式运行ant有什么不利之处吗？...或者有人能看到更好的方法吗？
答案 0 :(得分：1)
ANT构建步骤背后的主要思想是它提供跨平台的一致性。所以你应该尽可能多地使用它，以避免配置地狱＆＃34; - 不同配置数量的组合爆炸。然而，有时候，一个男人必须做一个男人必须做的事情。
答案 1 :(得分：1)
考虑到你的限制，我认为你的解决方案很好。
回答你的问题：
...is there any disadvantage of running ant in this manner...?
首先想到的是，如果你有一个分布式的Jenkins部署，一些运行Windows的从服务器，以及一些运行UNIX的从服务器，那么这显然不起作用（或者至少需要更多的工作 - 例如，安装/配置Cygwin）。但我不认为这是你真正关心的事情。
另一种可以说更清晰的解决方案是设置一个以root身份运行的Jenkins从属服务器（如果需要，可以在Windows上运行“管理员”）并将您的工作绑定到它，坚持为您调用“调用Ant”Ant调用。但这需要更多的工作来设置，并且可能不值得努力。
答案 2 :(得分：0)
答案 3 :(得分：0)
如果一切正常，使用shell中的ant似乎不成问题。正如您所提到的，修改后的文件权限可能是执行后的问题。