前言

前一篇Azure Pipeline 基本診斷技巧我們介紹了多種發現錯誤根本原因的方法，讓使用者可以快速排除問題，降低故障所造成的影響。許多使用者可能會遇到另一個問題是: Pipeline 預設會從 Azure Repository 拉取程式碼或 GitOps 設定，當 Git 流程中發生問題該如何進行診斷?與一般 Pipeline Task 診斷方式不同，在透過 System Diagnostics 取得的資訊幫助不大，平台管理者難以了解發生什麼事情。

個人經驗是企業用戶較常遇到此問題，多數為 Proxy 或 Firewall 環境需要進行 Git 問題診斷。除了網路存取問題外，其次遇到因流量因素或 Repository 容量過大造成的效能問題

如何進行 Git troubleshooting

一般來說，我們在開發環境發生 Git issue，在 Linux 命令列你可以透過下列指令設定環境，在執行 Git 時取得更多資訊以進行診斷。以 GIT_TRACE_PACKET 參數為例，將啟用網路封包層級追蹤，讓使用者可以了解網路存取階段發生什麼事情。您可以在 Git Internals - Environment Variables 找到更多相關說明

Linux 使用 export 設定環境變數；Windows 則是使用 set 設定環境變數

$ export GIT_TRACE=1
$ export GIT_TRACE_PACKET=1 
$ export GIT_CURL_NO_DATA=1
$ export GIT_CURL_VERBOSE=1

在沒有設定環境變數情況下，Git 操作只有簡易的訊息。

如果你設定了環境變數，網路連線資訊一目了然

相同的，使用者在 Azure Pipeline YAML 檔案進行下列設定，即會在 Pipeline 執行過程中印出更多資訊提供診斷使用。

variables:
  GIT_TRACE: '1'
  GIT_TRACE_PACKET: '1'
  GIT_TRACE_CURL_NO_DATA: '1'
  GIT_CURL_VERBOSE: '1'

隨後使用者在執行 Pipeline 的時候即可看見完整的 Git trace log.

其他最佳實踐

一般來說，每次在執行 Pipeline 的時候我們盡可能清除 Agent (代理程式) 的工作目錄。理所當然，也包含簽出的程式碼，以保持每次乾淨的執行，避免殘留檔案影響 Pipeline 結果。

使用微軟託管代理 (Cloud Agent 或 VMSS Agent) 則不需要額外設定，因為每次配置給你的都是 Agent，所以不需要額外設定清理。