本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
GitHub
GitHub 是適用於軟體開發的 Web 型託管服務,提供具有版本控制的程式碼儲存和管理服務。您可以使用 Amazon Kendra 為 GitHub Enterprise Cloud (SaaS) 和 GitHub Enterprise Server (On Prem) 儲存庫檔案編製索引、發出和提取請求、發出和提取請求評論,以及發出和提取請求評論附件。您也可以選擇包含或排除特定檔案。
注意
Amazon Kendra 現在支援升級的 GitHub 連接器。
主控台已為您自動升級。您在主控台中建立的任何新連接器都將使用升級的架構。如果您使用 API,您現在必須使用 TemplateConfiguration 物件,而不是 GitHubConfiguration
物件來設定連接器。
使用舊版主控台和 API 架構設定的連接器將繼續按設定運作。不過,您將無法編輯或更新它們。如果您想要編輯或更新連接器組態,則必須建立新的連接器。
建議您將連接器工作流程遷移至升級版本。使用較舊架構設定的連接器支援預計在 2024 年 6 月結束。
您可以使用 Amazon Kendra 主控台
如需對 Amazon Kendra GitHub 資料來源連接器進行故障診斷,請參閱 對資料來源進行故障診斷。
支援的功能
Amazon Kendra GitHub 資料來源連接器支援下列功能:
-
欄位映射
-
使用者存取控制
-
包含/排除篩選條件
-
完整和增量內容同步
-
虛擬私有雲端 (VPC)
先決條件
在您可以使用 Amazon Kendra 為 GitHub 資料來源編製索引之前,請在 GitHub 和 AWS 帳戶中進行這些變更。
在 GitHub 中,請確定您有:
-
建立具有 GitHub 組織管理許可的 GitHub 使用者。
-
在 Git Hub 中設定個人存取字符,以用作您的身分驗證憑證。請參閱有關建立個人存取字符的 GitHub 文件
。 注意
我們建議您定期重新整理或輪換您的登入資料和秘密。僅為您自己的安全提供必要的存取層級。我們不建議您在資料來源以及連接器 1.0 和 2.0 版 (如適用) 之間重複使用登入資料和秘密。
-
建議:設定身分驗證憑證的 OAuth 權杖。使用 OAuth 權杖以獲得更好的 API 節流限制和連接器效能。請參閱 OAuth 授權上的 GitHub 文件
。 -
記下您使用的 GitHub 服務類型的 GitHub 主機 URL。例如,GitHub 雲端的主機 URL 可以是
https://api.github.com
GitHub 伺服器的主機 URL 可以是https://on-prem-host-url/api/v3/
。 -
記下您要連線之 GitHub GitHub Enterprise Cloud (SaaS) 帳戶或 GitHub Enterprise Server (內部部署) 帳戶的組織名稱。您可以登入 GitHub 桌面並在設定檔圖片下拉式清單下選取您的組織,以尋找您的組織名稱。
-
選用 (僅限伺服器):產生 SSL 憑證,並複製存放在 Amazon S3 儲存貯體中的憑證路徑。如果您需要安全的 SSL 連線,您可以使用此功能連線至 GitHub。您可以直接在任何使用 OpenSSL 的電腦上產生自我簽署的 X509 憑證。如需使用 OpenSSL 建立 X509 憑證的範例,請參閱建立和簽署 X509 憑證。
-
新增下列許可:
對於 GitHub Enterprise Cloud (SaaS)
-
repo:status
– 授予公有和私有儲存庫中遞交狀態的讀取/寫入存取權。只有在授予其他使用者或服務存取私有儲存庫遞交狀態,而未授予存取程式碼的權限時,才需要此範圍。 -
repo_deployment
– 准許存取公有和私有儲存庫的部署狀態。只有在授予其他使用者或服務對部署狀態的存取權時,才需要此範圍,而不需要授予對程式碼的存取權。 -
public_repo
– 限制對公有儲存庫的存取。這包括對公有儲存庫和組織的程式碼、遞交狀態、儲存庫專案、協作者和部署狀態的讀取/寫入存取權。主宰公有儲存庫時也需要。 -
repo:invite
– 授予接受/拒絕邀請以在儲存庫上協同合作的能力。只有在授予其他使用者或服務對邀請的存取權,而未授予對程式碼的存取權時,才需要此範圍。 -
security_events
– 授予:讀取和寫入對程式碼掃描 API 中安全事件的存取權。只有在授予其他使用者或服務存取安全事件的權限,而未授予存取程式碼的權限時,才需要此範圍。 -
read:org
– 唯讀存取組織成員資格、組織專案和團隊成員資格。 -
user:email
– 授予使用者電子郵件地址的讀取存取權。Amazon Kendra 需要才能爬取 ACLs。 -
user:follow
– 授予追蹤或取消追蹤其他使用者的存取權。Amazon Kendra 需要才能爬取 ACLs。 -
read:user
– 授予讀取使用者設定檔資料的存取權。Amazon Kendra 需要才能爬取 ACLs。 -
workflow
– 授予新增和更新 GitHub 動作工作流程檔案的能力。如果相同的檔案 (具有相同的路徑和內容) 存在於相同儲存庫中的另一個分支上,則可以在沒有此範圍的情況下遞交工作流程檔案。
如需詳細資訊,請參閱 GitHub 文件中 OAuth 應用程式的範圍
。 對於 GitHub Enterprise Server (內部部署)
-
repo:status
– 授予公有和私有儲存庫中遞交狀態的讀取/寫入存取權。只有在授予其他使用者或服務存取私有儲存庫遞交狀態,而未授予存取程式碼的權限時,才需要此範圍。 -
repo_deployment
– 准許存取公有和私有儲存庫的部署狀態。只有在授予其他使用者或服務對部署狀態的存取權時,才需要此範圍,而不需要授予對程式碼的存取權。 -
public_repo
– 限制對公有儲存庫的存取。這包括對公有儲存庫和組織的程式碼、遞交狀態、儲存庫專案、協作者和部署狀態的讀取/寫入存取權。主宰公有儲存庫時也需要。 -
repo:invite
– 授予接受/拒絕邀請以在儲存庫上協同合作的能力。只有在授予其他使用者或服務對邀請的存取權,而未授予對程式碼的存取權時,才需要此範圍。 -
security_events
– 授予:讀取和寫入對程式碼掃描 API 中安全事件的存取權。只有在授予其他使用者或服務存取安全事件的權限,而未授予存取程式碼的權限時,才需要此範圍。 -
read:user
– 授予讀取使用者設定檔資料的存取權。Amazon Q Business 需要才能爬取 ACLs。 -
user:email
– 授予使用者電子郵件地址的讀取存取權。Amazon Q Business 需要才能爬取 ACLs。 -
user:follow
– 授予追蹤或取消追蹤其他使用者的存取權。Amazon Q Business 需要才能爬取 ACLs。 -
site_admin
– 授予網站管理員對 GitHub Enterprise Server Administration API 端點的存取權。 -
workflow
– 授予新增和更新 GitHub 動作工作流程檔案的能力。如果相同的檔案 (具有相同的路徑和內容) 存在於相同儲存庫中的另一個分支上,則可以在沒有此範圍的情況下遞交工作流程檔案。
如需詳細資訊,請參閱 GitHub 文件中 OAuth 應用程式的範圍
和GitHub開發人員中 OAuth 應用程式的範圍 。 -
-
檢查每個文件在 GitHub 和您計劃用於相同索引的其他資料來源中都是唯一的。您要用於索引的每個資料來源不得包含跨資料來源的相同文件。文件 IDs是索引的全域 ID,且每個索引必須是唯一的。
在您的 中 AWS 帳戶,請確定您有:
-
建立 Amazon Kendra 索引,如果使用 API, 會記下索引 ID。
-
為您的資料來源建立 IAM 角色,如果使用 API, 會記下 IAM 角色的 ARN。
注意
如果您變更身分驗證類型和登入資料,則必須更新您的 IAM 角色以存取正確的 AWS Secrets Manager 秘密 ID。
-
將您的 GitHub 身分驗證憑證存放在 AWS Secrets Manager 秘密中,如果使用 API, 會記下秘密的 ARN。
注意
我們建議您定期重新整理或輪換您的登入資料和秘密。僅為您自己的安全提供必要的存取層級。我們不建議您在資料來源以及連接器 1.0 和 2.0 版 (如適用) 之間重複使用登入資料和秘密。
如果您沒有現有的 IAM 角色或秘密,則可以在將 GitHub 資料來源連線到 時,使用 主控台建立新的 IAM 角色和 Secrets Manager 秘密 Amazon Kendra。如果您使用 API,則必須提供現有 IAM 角色和 Secrets Manager 秘密的 ARN,以及索引 ID。
連線指示
若要 Amazon Kendra 連線至 GitHub 資料來源,您必須提供 GitHub 資料來源的必要詳細資訊,讓 Amazon Kendra 可以存取您的資料。如果您尚未為 設定 GitHub Amazon Kendra,請參閱 先決條件。
進一步了解
若要進一步了解 Amazon Kendra 如何與您的 GitHub 資料來源整合,請參閱: