从 Build Pipeline 推送到本地 Azure DevOps Git答案

【问题标题】：Push to local Azure DevOps Git from Build Pipeline从 Build Pipeline 推送到本地 Azure DevOps Git
【发布时间】：2019-02-21 06:20:49
【问题描述】：

短版

谁能告诉我如何在 Azure DevOps 构建管道中设置“命令行脚本”任务，将更改推送到本地 Git 存储库（实际上是管道所基于的 Git 存储库）？

无论我尝试什么，我的脚本在打印后总是超时Pushing commits to git。

加长版

我们正在将现有的 Java/Maven 项目从 Jenkins 构建服务器迁移到 Azure DevOps 构建环境，并且我正在尝试设置一个模仿 Jenkins“发布暂存”功能的构建管道。

我的第一次尝试是直接在签出的源上调用 Maven 发布插件。这涉及到几个障碍，其中大部分我都能以一种或另一种方式克服：

标准的 Azure DevOps git 环境没有设置所需的配置值“user.email”和“user.name”；这可以通过在推送之前在单独的“命令行脚本”任务中调用 git config 来解决。
Azure DevOps 以“分离的 HEAD 状态”检出源 - 为解决此问题，设置脚本任务还调用 git checkout master。

设置完成后，我的 Maven 调用脚本会运行到发布插件尝试推送到 Git 的位置；读取日志文件中的相应行

[INFO] Executing: cmd.exe /X /C "git push https://xxx.visualstudio.com/YYY/_git/zzz refs/heads/master:refs/heads/master"
[INFO] Working directory: D:\a\1\s</code>

在那之后，在超时之前什么都不会发生（至少，什么都不会被记录）：

##[error]The operation was canceled.
##[section]Finishing: Maven pom.xml

为了找出导致此问题的原因，我尝试了一些方法，其中包括

禁用 maven 调用并直接从脚本调用 git push，
注册“存储”类型的 Git 凭证助手（假设身份验证问题导致超时），

但没有成功。我现在想不出如何让git push 工作了 - 有没有人可以帮助我？

P.S.：您可能会说，就 Azure DevOps 而言，我是一个新手，所以我肯定不知道该系统的所有技巧和功能。特别是，我不知道是否有任何东西可以提供与 Maven 发布插件相同的功能。我们确实使用 Azure DevOps 包管理，但我们希望为快照和发布版本保留单独的提要（就像 Nexus 等工具所做的那样），因此我们必须有一种机制来自动推进发布号、签出和签入以及构建打包的模块并将其发布到发布提要。

如果有人可以提出替代方法来实现这一目标，我也愿意接受建议。

【问题讨论】：

标签： git maven azure-devops azure-pipelines maven-release-plugin

【解决方案1】：

您不必为身份验证走 PAT 路线 - 根据 this，如果您的存储库与构建管道属于同一 Azure DevOps 项目，则凭据应该只是流动。您是否可能尚未授权构建代理写入您的存储库？需要两件事：

在您的 Azure DevOps 项目的 Project Settings -> Repositories 下，授予 Project Collection Build Service 实体 Contributor 权限适当的回购（或所有项目回购）。
允许脚本访问“代理作业”设置下的 OAuth 令牌：

还要注意一个错误的陷阱：这不适用于子模块操作，因为 DevOps 不会自动将凭据流向子模块实例，唯一的症状是静默挂起。找到手动传递凭据的解决方法here。

【讨论】：

如果您使用最新的基于 YAML 的 VSTS，“允许脚本访问 OAuth 令牌”，您需要在 azure-pipeline.yml 文件中的“”下使用“persistCredentials: true”步骤：-checkout: self" 见docs.microsoft.com/en-us/azure/devops/pipelines/scripts/…
这是正确答案，应该由操作标记为正确答案。
能否分享命令行脚本或将本地更改从管道推送到存储库的详细过程？我面临问题并发布了一个问题，这是链接stackoverflow.com/questions/57680490/…
我没有看到Additional options
最新版本：可以直接查看grant-version-control-permissions-to-the-build-service的方法。之后你就可以毫无问题地使用 git 命令了。

【解决方案2】：

对于 Azure Devops 现在的工作方式，答案已经过时。要在您的管道中启用授权，您应该在您的步骤中使用 checkout 架构属性，以便您可以为以后的 git 命令保留凭据。

- checkout: self
  persistCredentials: true

【讨论】：

【解决方案3】：

要将更改推送到 Azure DevOps，您应该将您的凭据集成到 Git 存储库 URL：

首先，如果没有PAT，请创建。

然后使用以下命令推送：

git push https://Personal%20Access%20Token:PAT@xxx.visualstudio.com/YYY/_git/zzz master

【讨论】：

非常感谢您的回答；使用 PAT 有效（即使在命令行任务中）。
PAT 不会在 90 天左右后过期吗？我的情况是我的构建过程修改了管道所基于的 Git 存储库中的一个文件，我想提交/推送该修改。让 Azure DevOps 构建更新自己的 Git 存储库没有更好的选择吗（因为它在自己的上下文中运行 - 它不像是外部源）？每隔几个月为运行代理的服务帐户生成 PAT 似乎很麻烦。
对此的另一个挑战是，如果我将我的 PAT 作为“秘密变量”存储在变量集中（因此它可以跨构建使用），它将无法工作。所以现在我必须将它作为明文存储在变量集中。它有效 - 我只是认为必须有更好的方法。
秘密变量不会自动填充到构建代理的环境变量中，因此对于 powershell 之类的东西，您需要使用任务的显式 Environment Variables 部分来提供剧本的秘密。至于过期时间，可以设置最长为12个月。
你可以使用 GitHub 应用，它不会过期。

【解决方案4】：

我在本地 DevOps 服务器中遇到了同样的问题（git push 挂起直到超时），即使正确设置了允许脚本访问 OAuth 令牌以及 Repo 权限。

在我的情况下，问题是 Build Agent 在 PATH 环境变量的开头添加了一个路径 - 对我来说它是 'C:\ins\agent\externals\git\cmd\'。这里有一个旧的 git 版本（git 版本 2.18.0.windows.1），并在构建代理管道的上下文中启动。您可以通过在构建任务中添加“git --version”调用来验证这一点。

我没有调查为什么旧的 git 版本不起作用，只是在管道任务中为我的最新 git.exe 使用了完整路径限定

“C:\Program Files\Git\bin\git.exe”推送源主

使用这个 git 版本 - 目前“git 版本 2.24.0.windows.2”一切正常。当然，将您的 Build Agent 更新到具有较新 git.exe 的版本也应该可以解决这个问题。

【讨论】：