简体   繁体   English

从构建管道推送到本地 Azure DevOps Git

[英]Push to local Azure DevOps Git from Build Pipeline

Short version精简版

Can someone tell me how to set up a "Command Line Script" task within an Azure DevOps build pipeline that pushes changes to a local Git repository (in fact, the Git repository on which the pipeline is based)?有人能告诉我如何在 Azure DevOps 构建管道中设置“命令行脚本”任务,将更改推送到本地 Git 存储库(实际上,管道所基于的 Git 存储库)?

No matter what I try, my script always times out after printing Pushing commits to git .无论我尝试什么,我的脚本在打印Pushing commits to git后总是超时。

Longer version更长的版本

We are migrating existing Java/Maven projects from a Jenkins build server to an Azure DevOps build environment, and I am trying to set up a build pipeline that mimics the Jenkins "Release Staging" functionality.我们正在将现有的 Java/Maven 项目从 Jenkins 构建服务器迁移到 Azure DevOps 构建环境,我正在尝试建立一个模仿 Jenkins“发布暂存”功能的构建管道。

My first attempt was to call the Maven release plugin directly on the checked out sources.我的第一次尝试是直接在检出的源上调用 Maven 发布插件。 This involved several obstacles, most of which I was able to overcome in one way or the other:这涉及到几个障碍,其中大部分我都能够以一种或另一种方式克服:

  1. The standard Azure DevOps git environment doesn't have the required config values "user.email" and "user.name" set;标准 Azure DevOps git 环境没有设置所需的配置值“user.email”和“user.name”; this can be solved by calling git config in a separate "Command Line Script" task prior to pushing.这可以通过在推送之前在单独的“命令行脚本”任务中调用git config来解决。
  2. Azure DevOps checks out the sources in a "detached HEAD state" - to solve this problem, the setup script tasks also calls git checkout master . Azure DevOps 在“分离的 HEAD 状态”中检出源 - 为了解决这个问题,安装脚本任务还调用git checkout master

Once this is set up, my Maven call script runs up to the point where the release plugin attempts to push to Git;一旦设置完成,我的 Maven 调用脚本就会运行到发布插件尝试推送到 Git 的位置; the corresponding lines in the log file read读取日志文件中的相应行

[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>

After that, nothing happens (at least, nothing gets logged) until the timeout strikes:在那之后,在超时到来之前,什么都没有发生(至少,没有任何记录):

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

In order to find out what causes this problem I tried a few things, among others,为了找出导致此问题的原因,我尝试了一些方法,其中包括

  • disabling the maven call and calling git push directly from the script,禁用 maven 调用并直接从脚本调用git push
  • registering a "store" type Git credential helper (assuming that an authentication problem is responsible for the timeout),注册一个“存储”类型的 Git 凭证助手(假设身份验证问题是导致超时的原因),

but without success.但没有成功。 I am now running out of ideas how I could get the git push call to work - is there anyone out here who can help me out?我现在没有想法如何让git push调用工作 - 有没有人可以帮助我?

PS: As you may be able to tell, I'm rather a newbie as far as Azure DevOps is concerned, so I surely don't know all tricks and features of that system. PS:正如您可能会说的,就 Azure DevOps 而言,我是一个新手,所以我肯定不了解该系统的所有技巧和功能。 In particular, I don't know if there is anything that offers the same functionality as the Maven release plugin.特别是,我不知道是否有任何提供与 Maven 发布插件相同的功能。 We do use the Azure DevOps package management, but we want to keep separate feeds for snapshots and for release builds (the way tools like Nexus do), so we have to have a mechanism for automatically advancing release numbers, checking out and back in and building and publishing the packaged module to the release feed.我们确实使用了 Azure DevOps 包管理,但我们希望为快照和发布版本保留单独的提要(就像 Nexus 这样的工具所做的那样),因此我们必须有一种机制来自动推进发布编号、检出和返回以及构建打包模块并将其发布到发布提要。

If someone can suggest an alternative way to achieve that, I'm open to suggestions as well.如果有人可以提出替代方法来实现这一目标,我也愿意接受建议。

You shouldn't have to go the PAT route for auth - according to this , if your repo is part of the same Azure DevOps project as the build pipeline, credentials should just flow.您不必走 PAT 路线进行身份验证 - 根据,如果您的存储库与构建管道属于同一个 Azure DevOps 项目,则凭证应该只是流动的。 Is it possible you haven't authorized the build agent to write to your repos?您是否可能没有授权构建代理写入您的存储库? Two things are needed:需要做两件事:

  • Under Project Settings -> Repositories for your Azure DevOps project, allow the Project Collection Build Service entity Contributor rights to the appropriate repo (or all project repos).在“项目设置”->“ Azure DevOps 项目的存储库”下,允许项目集合构建服务实体Contributor对相应存储库(或所有项目存储库)的权限。

  • Allow scripts to access the OAuth token under the "Agent job" settings:允许脚本在“代理作业”设置下访问 OAuth 令牌:

    在此处输入图片说明

Also note a bad gotcha: this won't work for submodule operations, since DevOps does not automatically flow the credentials to the submodule instances, and the only symptom is a silent hang.还要注意一个不好的问题:这不适用于子模块操作,因为 DevOps 不会自动将凭据流到子模块实例,唯一的症状是无提示挂起。 Workaround to flow credentials manually is found here .可以在此处找到手动传输凭据的解决方法。

The answers have become out of date with how Azure Devops works now.对于 Azure Devops 现在的工作方式,答案已经过时。 To enable authorisation in your pipeline you should use the checkout schema property in your steps so you can persist the credentials for later git commands.要在您的管道中启用授权,您应该在您的步骤中使用checkout架构属性,以便您可以为以后的 git 命令保留凭据。

- checkout: self
  persistCredentials: true

To push change to Azure DevOps, you should integrate your credential in Git repo URL :要将更改推送到 Azure DevOps,您应该将您的凭据集成到 Git 存储库 URL 中

  • First, create a PAT if you not have.首先,如果没有,请创建一个PAT
  • Then use below command to push:然后使用以下命令进行推送:

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

I've encountered the same problem (git push hangs till timeout) in on premise DevOps Server even if Allow scripts to access the OAuth token as well as Repo permissions were correctly set.即使正确设置了允许脚本访问 OAuth 令牌以及 Repo 权限,我在内部部署 DevOps 服务器中也遇到了同样的问题(git push 挂起直到超时)。

In my case the problem was that Build Agent adds a path at the beginning of PATH environment variable - for me it was 'C:\\ins\\agent\\externals\\git\\cmd\\'.在我的情况下,问题是 Build Agent 在 PATH 环境变量的开头添加了一个路径 - 对我来说它是'C:\\ins\\agent\\externals\\git\\cmd\\'。 Here an old git version (git version 2.18.0.windows.1) resided and was launched in the context of build agent's pipeline.这里有一个旧的 git 版本(git 版本 2.18.0.windows.1),并在构建代理管道的上下文中启动。 You can verify this by adding "git --version" call to your build task.您可以通过向构建任务添加“git --version”调用来验证这一点。

I haven't investigated why the old git version didn't work and simply used the full path qualification for my up-to-date git.exe in the pipeline task我还没有调查为什么旧的 git 版本不起作用,只是在管道任务中使用了我最新的 git.exe 的完整路径限定

"C:\\Program Files\\Git\\bin\\git.exe" push origin master "C:\\Program Files\\Git\\bin\\git.exe" 推送原点大师

and with this git version - currently "git version 2.24.0.windows.2" everything works well.使用这个 git 版本 - 目前“git 版本 2.24.0.windows.2”一切正常。 Updating your Build Agent to a version with newer git.exe should solve this problem too, of course.当然,将您的构建代理更新到具有较新 git.exe 的版本也应该可以解决此问题。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 从发布管道推送到本地 Azure DevOps Git - Push to local Azure DevOps Git from Release Pipeline 无法在 Azure Devops 管道中推送 git 标签 - Cannot push git tags in Azure Devops pipeline 在 Azure DevOps 管道内执行 git 推送但出现致命错误 - Execute git push within Azure DevOps pipeline but getting fatal error 无法使用 CI 管道从 Azure DevOps 中的外部 Git 触发源代码的自动构建 - Unable to trigger automatic build of source code from external Git in Azure DevOps Using CI pipeline 将 git 标签从 Azure 管道推送到 GitHub - Push git tags from Azure Pipeline to GitHub 在 Azure Devops 管道中:推送标签有效,但不推送 - In an Azure Devops pipeline: push tag works, but not push 在 Azure DevOps 中使用 Git 进行门控推送 - Gated Push with Git in Azure DevOps 从 Azure DevOps Pipeline 提交到 Git Repo 时文件夹重复 - Duplication of folders when committing to Git Repo from Azure DevOps Pipeline 如何从 Azure DevOps powershell 任务运行 git push 命令 - How to run git push command from Azure DevOps powershell task Azure DevOps 错误“Git fetch failed with exit code 128”在其他 git 存储库的构建管道期间 - Azure DevOps error 'Git fetch failed with exit code 128' during build pipeline of other git Repository
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM