簡體   English   中英

單個 Repo 下的 Azure DevOps 多構建管道在使用 Git 時耗盡構建服務器內存

[英]Azure DevOps Multiple Build pipeline under single Repo Drain the build server memory when using Git

我在單個存儲庫下有 20 多個解決方案。 即使我在觸發器下添加了路徑過濾器,每個構建管道結帳都會將整個存儲庫保存在構建代理 _work/x/s 文件夾下。 它正在耗盡服務器內存。 在這種情況下,任何人都可以幫助我為結帳應用路徑過濾器,或者每個構建管道都應該引用相同的源。 我正在使用 Git 管道。

在 Azure DevOps 中,我們無法選擇僅獲取存儲庫的一部分,但有一種解決方法:禁用“獲取源”步驟並通過在腳本中手動執行相應的 git 命令來僅獲取所需的源。

一種。 禁用“獲取來源”

- checkout: none

在管道中添加任務cmdPowerShell以使用git sparse-checkout手動獲取源。 例如,只獲取 test 文件夾中的目錄 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

您可以參考這張以獲取更多詳細信息

假設使用內存,您的意思是磁盤空間,我可以看到 20 個解決方案,具有自己的管道,每個都有自己的工作文件夾,會導致它消耗大量磁盤空間。 每個管道都有自己的工作區文件夾,這是為了讓它們可以獨立更改,同時為它們提供最大的速度。 在您的情況下,每個管道訪問相同的 repo,但每個管道可能具有不同的 repo 設置。 這樣代理就不必關心這個了。

有幾個選項,其他人已經提到了一些選項。

  1. 使用淺克隆。 您可以將管道配置為最多只獲取 X 次提交的歷史記錄 這可能會大大減少每個管道的工作文件夾大小,但如果您構建許多不同的分支,可能會減慢您的構建速度。 您可以通過將 fetchDepth 設置為一個小數字來啟用淺克隆。 如果您依賴 GitVersion 來計算內部版本號,或任何其他依賴於 repo 歷史的任務,當將 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 (eg \\_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
  2. 在每次構建結束時進行清理。 您可以在管道的末尾添加一個腳本步驟來清理本地工作文件夾。 帶有condition: always()簡單腳本步驟condition: always()應該可以解決問題。 這樣,您可以在構建完成后從驅動器中刪除大型構建輸出。 您可以使用 YAML 模板將此任務自動注入每個 job/pipeline

  3. 控制結帳過程正如其他人提到的,您可以告訴 Pipelines 不結帳 repo,這樣您就可以自己控制該過程。 您在這里有幾個選擇:

     - checkout: none

    一種。 worktree此命令將允許您的構建管道共享其.git文件夾 不是每次都克隆 repo,而是克隆一次,然后每個管道在$(build.sourcesdirectory)創建一個新的工作樹。 這可以節省大量空間,同時保留構建代理上的所有歷史記錄,以實現快速分支切換和對 gitversion 等工具的支持。 按照 Vitu Liu 的一般步驟操作

    sparse-checkout此命令將允許您配置要在本地工作目錄中sparse-checkout文件夾。 git 命令行客戶端足夠聰明,可以只獲取這些文件夾所需的數據。 按照 Vitu Liu 的步驟操作

    C。 使用自定義結帳任務 此自定義結帳任務將使用代理上的單個文件夾並使用符號鏈接來確保每個管道在后台使用相同的 repo 不過它似乎沒有發布到市場上,所以如果使用 tfx-cli,你必須安裝。

     cd drive:\\path\\to\\extracted\\zip tfx login tfx build tasks upload --task-path .
  4. 創建單個管道並包含參數化的 YAML 文件 通過創建單個管道,代理將創建單個工作文件夾。 然后,根據更改的文件,執行您要構建的解決方案的管道文件。 請參閱在運行時選擇的參數文檔 其他答案已經解釋了如何使用 git 命令行迭代已更改的文件並根據其結果設置變量

     steps: - ${{ if eq(parameters.experimentalTemplate, true) }}: - template: experimental.yml - ${{ if not(eq(parameters.experimentalTemplate, true)) }}: - template: stable.yml
  5. 使用新的規模集代理 Azure Pipelines 現在提供了一種以托管管道運行的相同方式設置您自己的代理的方法 優點之一是您可以控制何時重置圖像。 基本上允許您在每次構建時都擁有一個干凈的映像,並且預安裝了所有依賴項或預填充了 npm/nuget 緩存。 低成本並行化功能可能對您的場景也非常有用。

  6. 配置維護,您可以在代理池上啟用清理作業。 它將排隊一個特殊的工作來清理工作文件夾、舊任務、臨時文件等。如果不是所有 20 個解決方案都在同一天運行,它可能會有所幫助。 您可以在帳戶級別找到此選項。

    在帳戶級別在代理池上啟用維護作業。

Azure Pipelines Agent repo 上有一個 未解決的問題

注意:您尚未提供 YAML 文件以供參考,因此做出一些標准假設,即您使用的是簡單的 YAML 架構。

單個 repo 中的多個解決方案,因此是經典的 mono repo 設置。 你正在看這樣的東西。

- script: npm install
  workingDirectory: service-b/

更改 YAML 中 CICD 管道代碼開頭的工作目錄。 一旦成為工作目錄,其余部分與您現有的 YAML 一樣正常

注意幾點。

  • 可以根據特定的文件夾更改設置觸發器。 所以,如果你有

存儲庫根 --ProjectOne --ProjectTwo 。 . . --項目三

可以為每個文件夾設置觸發器,然后在您的 YAML 中更改工作目錄,並相應地開展您的業務。

  • 此外,對於部署,如果您是新手,我會簡單地為每個項目構建一個新管道以使其變得容易。

  • 或者,如果您真的想將所有內容都放在一個文件中,您可以添加條件並在單個 YAML 中路由整個 Mono 存儲庫。 根據特定變量(例如,項目名稱),您可以將部署路由到所需目標。

在以下位置了解更多詳情。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM