我目前正在使用 jenkins 在预期的发布条件下部署应用程序，并且我被迫以 root 用户身份在已部署的系统上运行 JUnit 测试（因为该应用程序具有某些只能由 root 访问的文件）。
我没有使用“调用 ant”构建步骤来运行测试，而是使用“执行 shell”构建步骤中的 sudo 来运行 ant，例如...
sudo ant -file build.xml -D.... test
因为 jenkins 用户具有执行此操作的必要 root 权限，但不能访问上述文件。
我意识到这样做会在工作区中创建一些具有错误权限的文件夹，但我在“执行 shell”之后更正了这个问题。
一切似乎都很好，但感觉像是一种解决方法。
那么我的问题是，与构建步骤“调用蚂蚁”相比，以这种方式运行蚂蚁有什么缺点吗？......或者有人能看到更好的方法吗？
鉴于您的限制，我认为您的解决方案很好。
要回答您的问题：
...is there any disadvantage of running ant in this manner...?
首先想到的是，如果你有一个分布式 Jenkins 部署，一些从属运行 Windows，一些从属运行 UNIX，那么这显然行不通（或者至少需要更多的工作——例如，安装/配置 Cygwin ）。但我不认为这是你真正关心的事情。
另一种可以说是更干净的解决方案是设置一个以 root 身份运行的 Jenkins 从属设备（如果需要，还可以在 Windows 上运行“管理员”）并将您的工作与它联系起来，坚持为您的 Ant 调用“调用 Ant”。但这需要更多的工作来设置，而且可能不值得付出努力。
詹金斯用一个shell命令翻译“invoke ant”，你可以检查这个观察构建的控制台输出，所以如果你按照你说的方式解决了你的问题，我认为它是一样的
ANT 构建步骤背后的主要思想是它提供跨平台的一致性。所以你应该尽可能地使用它，以避免“配置地狱”——不同配置数量的组合爆炸。然而，有时候，男人必须做男人必须做的事。
如果一切正常，从 shell 中使用 ant 似乎没有问题。正如您所提到的，修改后的文件权限可能是执行后的问题。