单个Repo下的Azure DevOps多个构建管道使用Git时耗尽构建服务器内存

问题描述

我在单个存储库下有20多个解决方案。即使我在触发器下添加了路径过滤器，每个构建管道结帐也将整个存储库保存在构建代理_work / x / s文件夹下。它正在耗尽服务器内存。在这种情况下，任何人都可以帮助我为结帐应用路径过滤器，否则每个构建管道都应引用相同的源。我正在使用Git管道。

解决方法

在Azure DevOps中，我们没有选择仅获取存储库的一部分的方法，但是有一种解决方法：禁用“获取源代码”步骤，并通过手动执行相应的git命令仅获取所需的源代码。脚本。

a。禁用“获取来源”

- checkout: none

b。在管道中，添加任务cmd或PowerShell以使用git sparse-checkout手动获取源。例如，仅获得测试文件夹中的目录src_1和src_2

parameters:
  access: '{personal access token}'
  repository: '{dev.azure.com/organisation/project/_git/repository}'
  sourcePath: '{path/to/files/}'

- task: CmdLine@2
      inputs:
        script: |
          ECHO ##[command] git init
          git init
          ECHO ##[command] git sparse-checkout: ${{ parameters.sourcePath }}
          git config core.sparsecheckout true
          echo ${{ parameters.sourcePath }} >> .git/info/sparse-checkout
          ECHO ##[command] git remote add origin https://${{ parameters.repository }}
          git remote add origin https://${{ parameters.access }}@${{ parameters.repository }}
          ECHO ##[command] git fetch --progress --verbose --depth=1 origin master
          git fetch --progress --verbose --depth=1 origin master
          ECHO ##[command] git pull --progress --verbose origin master
          git pull --progress --verbose origin master

您可以参考此ticket以获得更多详细信息

假设使用内存，您的意思是磁盘空间，我可以看到有自己的管道，每个都有自己的工作文件夹的20个解决方案如何消耗大量磁盘空间。每个管道都有其自己的工作区文件夹，这是为了使它们可以独立更改，但速度却最大。在您的情况下，每个管道都访问相同的存储库，但每个存储库可能具有不同的存储库设置。这样，座席不必在意。

有一些选择，有些已经被其他人提及。

使用浅表克隆。 You can configure the pipeline to only fetch up to X amount of commits of history。这可能会大大减少每个管道的工作文件夹大小，但是如果您构建许多不同的分支，则可能会使构建速度变慢。您可以通过将fetchDepth设置为较小的值来启用浅层克隆。如果您依赖GitVersion来计算内部版本号，或依赖回购历史记录的任何其他任务，则在将fetchDepth设置得太低时，它们可能会中断。

steps:
- checkout: self | none | repository name # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # if true,run `execute git clean -ffdx && git reset --hard HEAD` before fetching
  fetchDepth: number  # the depth of commits to ask Git to fetch; defaults to no limit
  lfs: boolean  # whether to download Git-LFS files; defaults to false
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules; defaults to not checking out submodules
  path: string  # path to check out source code,relative to the agent's build directory (e.g. \_work\1); defaults to a directory called `s`
  persistCredentials: boolean  # if 'true',leave the OAuth token in the Git config after the initial fetch; defaults to false

在每次构建结束时进行清理。。您可以在管道末尾添加脚本步骤以清理本地工作文件夹。一个简单的condition: always()脚本步骤就可以解决问题。这样，您可以在构建完成后从驱动器中删除大型构建输出。 You could use a YAML template to auto-inject this task into every job/pipeline。
控制结帐流程正如其他人所述，您可以告诉Pipelines不要结帐仓库，这样您就可以自己控制该流程。您在这里有一些选择：
```
    - checkout: none
```
a。 worktree ，this command will allow your build pipelines to share their .git folder。不必克隆每个仓库，而是克隆一次，然后每个管道在$(build.sourcesdirectory)中创建一个新的工作树。这可以节省大量空间，但保留了构建代理程序上的所有历史记录，以实现快速的分支切换和对gitversion等工具的支持。 Follow the general steps from Vitu Liu。

b。 sparse-checkout 此命令将允许您配置要在本地工作目录中检出的文件夹。 git命令行客户端足够聪明，也只获取那些文件夹所需的数据。 Follow the steps from Vitu Liu。

c。使用自定义结帐任务。 This custom checkout task will use a single folder on the agent and uses a symlink to make sure each pipeline uses the same repo under the hood。不过，它似乎似乎还没有发布到市场上，因此，如果使用tfx-cli，则必须进行安装。
```
cd drive:\path\to\extracted\zip
tfx login
tfx build tasks upload --task-path .
```
创建一个管道并包含参数化的YAML文件。通过创建单个管道，代理将创建单个工作文件夹。然后，根据更改的文件，执行要构建的解决方案的管道文件。 See the Parameters to select at runtime docs。其他答案已经说明了如何use the git command line to iterate the files that have changed and setting a variable based on their outcome。
```
steps:
- ${{ if eq(parameters.experimentalTemplate,true) }}:
  - template: experimental.yml
- ${{ if not(eq(parameters.experimentalTemplate,true)) }}:
  - template: stable.yml
```
使用新的规模设置代理。 Azure Pipelines now offers a way to setup your own agent in the same way the hosted pipelines run。优点之一是您可以控制何时重置图像。基本上，您可以在每个构建版本中都具有一个干净的映像，并预先安装所有依赖项或预先填充npm / nuget缓存。低成本的并行化功能对于您的情况可能也非常有用。
配置维护，您可以在代理程序池上启用清理作业。它将排队一个特殊的作业来清理工作文件夹，旧任务，临时文件等。如果并非所有20个解决方案都在同一天运行，它可能会有所帮助。您可以在帐户一级找到此选项。

有一个open issue on the Azure Pipelines Agent repo。

注意：您尚未提供您的YAML文件以供参考，因此请作一些标准的假设，即您使用的是简单的YAML模式。

单个回购中有多个解决方案，因此是经典的单回购设置。你正在看这样的东西。

- script: npm install
  workingDirectory: service-b/

在YAML中的CICD管道代码的开头更改工作目录。进入工作目录后，其余的将与您现有的YAML照常进行

注意几件事。

可以根据特定的文件夹更改设置触发器。所以，如果你有

存储库根 --ProjectOne -工程二。。。 --ProjectThree

可以为每个文件夹设置触发器，然后在YAML中更改工作目录，并据此开展业务。

此外，对于部署，如果您是新手，我将为每个项目简单地建立一个新管道以使其变得简单。
或者，如果您确实希望将其全部保存在一个文件中，则可以添加条件并在单个YAML中路由整个mono库。根据特定变量（例如，项目名称），可以将部署路由到所需的目标。