（几乎）相同的 Jenkins 项目，一个成功，一个失败答案

【问题标题】：(Nearly) Identical Jenkins projects, one works, one fails（几乎）相同的 Jenkins 项目，一个成功，一个失败
【发布时间】：2017-11-06 19:47:11
【问题描述】：

我有两个相同的 Jenkins 项目，除了正在使用的存储库。 Jenkins 正在为两者运行 ant 构建并使用不同的目标。

除了引用不同的分支外，这两个目标实际上做同样的事情。一个项目有效，其他错误。

失败的项目错误：

 [exec] bash: /dev/tty: No such device or address
 [exec] error: failed to execute prompt script (exit code 1)
 [exec] fatal: could not read Password for 'https://****@git.ersp.net': No error
 [exec] Result: 128

我已经查看了这个问题，我发现的似乎与正在使用的其他实用工具有关，例如 Atom、Winpty 等。我们不使用这些工具，但我们正在使用 使用 bash。

问题似乎源于 bash 无法请求用户名和密码，但这些是由 Jenkins 提供的（两个项目相同）。

我在 Jenkins 中更新了我的凭据，以确保这不是问题所在。第一个项目继续通过，而第二个项目继续失败，它们使用相同的凭据。

蚂蚁目标

<!-- RELEASE GIT -->
<target name="update-release-git">      
    <exec executable="C:\Program Files\Git\cmd\git.exe">
        <arg value="-C" />
        <arg value="${testing-release}" />          
        <arg value="checkout" />
        <arg value="${BRANCH}" />
    </exec> 
    <exec executable="C:\Program Files\Git\cmd\git.exe">
        <arg value="-C" />
        <arg value="${testing-release}" />          
        <arg value="fetch" />
    </exec> 
</target>

<!-- EPIC1 GIT -->
<target name="update-epic1">
    <exec executable="C:\Program Files\Git\cmd\git.exe">
        <arg value="-C" />
        <arg value="${testing-epic1}" />            
        <arg value="checkout" />
        <arg value="${BRANCH}" />
    </exec> 
    <exec executable="C:\Program Files\Git\cmd\git.exe">
        <arg value="-C" />
        <arg value="${testing-epic1}" />            
        <arg value="fetch" />
    </exec> 
</target>

EPIC1 有效，而 RELEASE 无效。它们都是同一个 repo 的克隆，只是使用了不同的分支。

任何帮助将不胜感激，谢谢！

编辑澄清一下，这些作业是独立运行的。

凭证信息通过 Jenkins 凭证管理器传递。在 Source Code Management > Git 下，您选择 repo url，然后凭据是已添加到 Jenkins 的可用凭据的选择选项。

【问题讨论】：

如果您更改顺序，首先是 EPIC1 和 RELEASE，会发生什么？您是如何将凭据传递给 ANT 的？
似乎没有什么不同，同样的问题。为了澄清它们不会背靠背运行，它们应该独立运行。我会用这个和凭证传递来更新帖子。

标签： git jenkins ant

【解决方案1】：

如果你乱七八糟地混合构建脚本和源代码管理，你总是会过得很糟糕。

让 jenkins 处理 git 的签出。总是。如果您的 ant 脚本破坏了您的工作副本，您会妨碍 jenkins 显示变更集的能力，这反过来又会破坏通知那些已提交该构建或自上次成功以来的能力的能力。以及当有人对分支上的构建脚本进行更改时的混乱（在脚本启动后更改分支时将不起作用。

跳过密码并使用 ssh 密钥进行身份验证可能更容易。

希望一旦你停止尝试执行到 git，你会处于一个好的位置。

【讨论】：