組建 GitHub Enterprise Server 存放庫

您可以將內部部署 GitHub Enterprise 伺服器與 Azure Pipelines 整合。 您的內部部署伺服器可能會對網際網路公開,或可能不會。

如果您的 GitHub Enterprise 伺服器可從執行 Azure Pipelines 服務的伺服器連線,則:

  • 您可以設定傳統組建和 YAML 管線
  • 您可以設定 CI、PR 和排程觸發程式

如果您的 GitHub Enterprise 伺服器無法從執行 Azure Pipelines 服務的伺服器連線,則:

  • 您只能設定傳統組建管線
  • 您只能啟動手動或已排程的組建
  • 您無法設定 YAML 管線
  • 您無法為傳統組建管線設定 CI 或 PR 觸發程式

如果您的內部部署伺服器可從 Microsoft 裝載的代理程式連線,您就可以使用它們來執行管線。 否則,您必須設定可以存取內部部署伺服器並提取程式碼的自我裝載代理程式。

可從 Azure Pipelines

要檢查的第一件事是您的 GitHub Enterprise 伺服器是否可從 Azure Pipelines 服務連線。

  1. 在您的 Azure DevOps UI 中,流覽至您的專案設定,然後選取 [ Pipelines] 底下的 [服務連接]。
  2. 選取 [新增服務連線],然後選擇 [ GitHub Enterprise Server ] 作為連線類型。
  3. 輸入所需的資訊,以建立 GitHub Enterprise 伺服器的連線。
  4. 在 [服務連線] 面板中選取 [ 驗證 ]。

如果驗證通過,則執行 Azure Pipelines service 的伺服器可以連線到您的內部部署 GitHub Enterprise 伺服器。 您可以繼續並設定連接。 然後,當您建立傳統組建或 YAML 管線時,可以使用此服務連接。 您也可以設定管線的 CI 和 PR 觸發程式。 Azure Pipelines 中使用 GitHub 的大部分功能也適用于 GitHub Enterprise 伺服器。 請參閱GitHub的檔,以瞭解這些功能。 以下是一些差異:

  • GitHub 與 Azure Pipelines 之間的整合是透過 GitHub marketplace 中的 Azure Pipelines 應用程式更容易進行。 此應用程式可讓您設定整合,而不需要依賴特定使用者的 OAuth 權杖。 我們沒有適用于 GitHub Enterprise Server 的類似應用程式。 因此,您必須使用 PAT、使用者名稱和密碼,或 OAuth 來設定 Azure Pipelines 與 GitHub Enterprise 伺服器之間的連接。
  • 使用 GitHub 時,Azure Pipelines 支援許多安全性功能,以驗證來自外部分支的貢獻。 例如,儲存在管線中的秘密不會提供給執行中的工作使用。 使用 GitHub Enterprise server 時,不提供這些保護。
  • GitHub Enterprise server 無法使用批註觸發程式。 您無法使用 GitHub Enterprise server 存放庫提取要求中的批註來觸發管線。
  • GitHubGitHub Enterprise server 無法使用檢查。 所有狀態更新都是透過基本狀態進行。

無法從 Azure Pipelines

當上一節所述的 GitHub Enterprise Server 連接驗證失敗時,Azure Pipelines 無法與您的伺服器通訊。 這可能是因為您的商業網路的設定方式所造成。 例如,您網路中的防火牆可能會防止外部流量抵達您的伺服器。 在此情況下,您有兩個選項:

  • 與您的 IT 部門合作,開啟 Azure Pipelines 與 GitHub Enterprise Server 之間的網路路徑。 例如,您可以將例外狀況新增至防火牆規則,以允許來自 Azure Pipelines 流量的流量。 請參閱Azure DevOps ip的一節,以查看您需要允許的 IP 位址。 此外,您必須有 GitHub Enterprise 伺服器的公用 DNS 專案,才能讓 Azure Pipelines 將伺服器的 FQDN 解析為 IP 位址。 在這些變更中,嘗試在 Azure Pipelines 中建立並驗證 GitHub Enterprise 的伺服器連接。

  • 您可以使用其他 Git連線,而不是使用 GitHub Enterprise 的伺服器連接。 請務必取消核取 [嘗試從 Azure Pipelines 存取此 Git 伺服器] 選項。 使用此連線類型,您只能設定傳統組建管線。 CI 和 PR 觸發程式將無法在此設定中運作。 您只能啟動手動或排程的管線執行。

可從 Microsoft 裝載的代理程式連線

您可能必須做的另一項決定是要使用 Microsoft 裝載的代理程式或自我裝載的代理程式來執行您的管線。 這通常是由 Microsoft 裝載的代理程式是否可以連線到您的伺服器。 若要檢查是否可以,請建立簡單的管線以使用 Microsoft 裝載的代理程式,並務必新增從伺服器簽出原始程式碼的步驟。 如果通過,則您可以繼續使用 Microsoft 裝載的代理程式。

無法從 Microsoft 裝載的代理程式連線

如果上述區段中所述的簡單測試管線因錯誤而失敗 TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting ,則無法從 Microsoft 裝載的代理程式連線到 GitHub Enterprise 的伺服器。 這可能是因為防火牆封鎖來自這些伺服器的流量所造成。 在此情況下,您有兩個選項:

  • 與您的 IT 部門合作,開啟 Microsoft 裝載的代理程式與 GitHub Enterprise Server 之間的網路路徑。 請參閱 Microsoft 託管代理程式中的 網路 功能一節。

  • 切換至使用 自我裝載的代理程式擴展集代理程式。 您可以在網路中設定這些代理程式,因此將可存取 GitHub Enterprise 伺服器。 這些代理程式只需要 Azure Pipelines 的輸出連線。 不需要針對輸入連線開啟防火牆。 確定您在建立 GitHub Enterprise 伺服器連線時所指定的伺服器名稱,可從自我裝載的代理程式進行解析。

Azure DevOpsIP 位址

Azure Pipelines 將要求傳送至 GitHub Enterprise Server 以:

  • 在管線建立期間查詢存放庫清單 (傳統和 YAML 管線)
  • 在管線建立期間尋找現有的 YAML 檔案 (YAML 管線)
  • 簽入 YAML 檔 (YAML 管線)
  • 在管線建立期間註冊 webhook (傳統和 YAML 管線)
  • (YAML 管線呈現 YAML 檔案的編輯器)
  • 在執行 (YAML 管線之前,先解析範本並展開 YAML 檔案)
  • 檢查自從上次排程執行 (傳統和 YAML 管線之後是否有任何變更)
  • 在 (傳統和 YAML 管線的使用者介面中,提取最新認可和顯示的詳細資料)

您可以觀察到 YAML 管線基本上需要 Azure Pipelines 與 GitHub Enterprise 伺服器之間的通訊。 因此,如果 Azure Pipelines 看不到 GitHub Enterprise 伺服器,就不可能設定 YAML 管線。

當您使用其他 Git連接來設定傳統管線時,請停用 Azure Pipelines 服務與 GitHub Enterprise 伺服器之間的通訊,並使用自我裝載的代理程式來建立程式碼,您將會獲得更佳的體驗:

  • 您必須在建立管線期間手動輸入存放庫的名稱
  • 您無法使用 CI 或 PR 觸發程式,因為 Azure Pipelines 無法在 GitHub Enterprise 伺服器中註冊 webhook
  • 只有在有變更時,才可使用排程觸發程式搭配選項來建立
  • 您無法在使用者介面中查看最新認可的相關資訊

如果您想要設定 YAML 管線,或是想要加強傳統管線的使用經驗,請務必啟用從 Azure Pipelines 到 GitHub Enterprise 伺服器的通訊。

若要允許來自 Azure DevOps 的流量抵達您的 GitHub Enterprise 伺服器,請將輸入連線中指定的 IP 位址或服務標籤新增至防火牆的允許清單。 如果您使用 ExpressRoute,請務必也將 EXPRESSROUTE IP 範圍 包含在防火牆的允許清單中。

常見問題集

GitHub Enterprise 整合的相關問題可分為下列類別:

  • 失敗的觸發程式: 當我將更新推送至存放庫時,不會觸發我的管線。
  • 失敗簽出 正在觸發我的管線,但在結帳步驟中會失敗。
  • 錯誤的版本 我的管線會執行,但它會使用未預期的來源/YAML 版本。

失敗的觸發程式

我剛剛建立了具有 CI/PR 觸發程式的新 YAML 管線,但不會觸發管線。

遵循下列每個步驟,針對失敗的觸發程式進行疑難排解:

  • YAML CI 或 PR 觸發程式是否 由 UI 中的管線設定覆寫? 編輯您的管線時,請選擇 [ ... ],然後選取 [ 觸發程式]。

    管線設定 UI。

    請在您的存放庫中,核取 [ 從此處覆寫 YAML 觸發 程式的類型] (持續整合提取要求驗證) 。

    從這裡覆寫 YAML 觸發程式。

  • webhook 可用來將 GitHub Enterprise 的更新傳達給 Azure Pipelines。 在 GitHub Enterprise 中,流覽至存放庫的設定,然後 webhook。 確認 webhook 存在。 通常您應該會看到兩個 webhook 推播,pull_request。 如果您沒有這麼做,則必須重新建立服務連線,並更新管線以使用新的服務連接。

  • 選取 GitHub Enterprise 中的每個 webhook,並確認對應至使用者認可的承載存在且已成功傳送至 Azure DevOps。 如果事件無法傳達給 Azure DevOps,您可能會在這裡看到錯誤。

  • 當 Azure Pipelines 從 GitHub 接收通知時,它會嘗試聯繫 GitHub 並取得有關存放庫和 YAML 檔案的詳細資訊。 如果 GitHub Enterprise 伺服器位於防火牆後方,此流量可能不會到達您的伺服器。 請參閱Azure DevOps IP 位址,並確認您已授與所有必要 ip 位址的例外狀況。 這些 IP 位址可能已變更,因為您原先設定例外狀況規則。

  • 您的管線已暫停或停用嗎? 開啟管線的編輯器,然後選取要檢查設定。 如果您的管線已暫停或停用,則觸發程式將無法運作。

  • 您是否已更新正確分支中的 YAML 檔案? 如果您將更新推送至分支,則相同分支中的 YAML 檔案會控制 CI 行為。 如果您將更新推送至來源分支,則藉由合併來源分支與目標分支所產生的 YAML 檔,會控制 PR 行為。 請確定正確分支中的 YAML 檔案具有必要的 CI 或 PR 設定。

  • 您是否已正確設定觸發程式? 當您定義 YAML 觸發程式時,您可以同時指定分支、標記和路徑的 include 和 exclude 子句。 請確定 include 子句符合您認可的詳細資料,而且 exclude 子句不會排除它們。 請檢查觸發程式的語法,並確定它是正確的。

  • 您是否已在定義觸發程式或路徑中使用了變數? 這是不支援的。

  • 您是否使用 YAML 檔案的範本? 如果是的話,請確定您的觸發程式是在主要 YAML 檔中定義的。 不支援在範本檔案內定義的觸發程式。

  • 您是否已排除推送變更的分支或路徑? 藉由將變更推送至內含分支中包含的路徑進行測試。 請注意,觸發程式中的路徑會區分大小寫。 在指定觸發程式中的路徑時,請確定您使用的是與實際資料夾相同的大小寫。

  • 您只是推送新的分支嗎? 如果是,新的分支可能無法啟動新的執行。 請參閱「建立新的分支時觸發程式的行為」一節。

我的 CI 或 PR 觸發程式的運作正常。 但現在已停止運作。

請先完成上一個問題中的疑難排解步驟。 然後,請遵循下列其他步驟:

  • 您的 PR 中有合併衝突嗎? 如果 PR 未觸發管線,請開啟它,並檢查它是否有合併衝突。 解決合併衝突。

  • 您是否遇到處理推送或 PR 事件的延遲? 您通常可以藉由查看問題是否專屬於單一管線,或在專案中的所有管線或存放庫通用,來進行驗證。 如果任何存放庫的推送或 PR 更新出現此徵兆,可能是因為處理更新事件而發生延遲。 檢查我們的 狀態頁面是否遇到服務中斷。 如果 [狀態] 頁面顯示問題,表示我們的小組必須已開始處理。 請經常檢查頁面,以取得問題的更新。

失敗簽出

您是否使用 Microsoft 託管的代理程式? 若是如此,這些代理程式可能無法連接到您的 GitHub Enterprise 伺服器。 如需詳細資訊,請參閱 Microsoft 裝載的 代理程式無法 連線。

錯誤的版本

在管線中使用的 YAML 檔案版本錯誤。 這是為什麼?

  • 針對 CI 觸發程式,系統會評估您正在推送之分支中的 YAML 檔案,以查看是否應該執行 CI 組建。
  • 針對 PR 觸發程式,會評估從提取來源和目標分支所產生的 YAML 檔案,以查看是否應該執行 PR 組建。