GitHub
GitHub is a web-based hosting service for software development providing code storage and management services with version control. You can use Amazon Kendra to index your GitHub Enterprise Cloud (SaaS) and GitHub Enterprise Server (On Prem) repository files, issue and pull requests, issue and pull request comments, and issue and pull request comment attachments. You can also choose to include or exclude certain files.
Note
Amazon Kendra now supports an upgraded GitHub connector.
The console has been automatically upgraded for you. Any new connectors you create in
the console will use the upgraded architecture. If you use the API, you must now use the
TemplateConfiguration object instead of the
GitHubConfiguration
object to configure your
connector.
Connectors configured using the older console and API architecture will continue to function as configured. However, you won’t be able to edit or update them. If you want to edit or update your connector configuration, you must create a new connector.
We recommended migrating your connector workflow to the upgraded version. Support for connectors configured using the older architecture is scheduled to end by June 2024.
You can connect Amazon Kendra to your GitHub data source using the Amazon Kendra console
For troubleshooting your Amazon Kendra GitHub data source connector, see Troubleshooting data sources.
Supported features
Amazon Kendra GitHub data source connector supports the following features:
-
Field mappings
-
User access control
-
Inclusion/exclusion filters
-
Full and incremental content syncs
-
Virtual private cloud (VPC)
Prerequisites
Before you can use Amazon Kendra to index your GitHub data source, make these changes in your GitHub and AWS accounts.
In GitHub, make sure you have:
-
Created a GitHub user with administrative permissions to the GitHub organization.
-
Configured a personal access token in Git Hub to use as your authentication credentials. See GitHub documentation on creating a personal access token
. Note
We recommend that you regularly refresh or rotate your credentials and secret. Provide only the necessary access level for your own security. We do not recommend that you re-use credentials and secrets across data sources, and connector versions 1.0 and 2.0 (where applicable).
-
Recommended:Configured an OAuth token for authentication credentials. Use OAuth token for better API throttle limits and connector performance. See GitHub documentation on OAuth authorization
. -
Noted the GitHub host URL for the type of GitHub service that you use. For example, the host URL for GitHub cloud could be
https://api.github.com
and the host URL for GitHub server could behttps://on-prem-host-url/api/v3/
. -
Noted the name of your organization for GitHub the GitHub Enterprise Cloud (SaaS) account or GitHub Enterprise Server (on-premises) account you want to connect to. You can find your organization name by logging into GitHub desktop and selecting Your organizations under your profile picture dropdown.
-
Optional (server only): Generated a SSL certificate and copied the path to the certificate stored in an Amazon S3 bucket. You use this to connect to GitHub if you require a secure SSL connection. You can simply generate a self-signed X509 certificate on any computer using OpenSSL. For an example of using OpenSSL to create an X509 certificate, see Create and sign an X509 certificate.
-
Added the following permissions:
For GitHub Enterprise Cloud (SaaS)
-
repo:status
– Grants read/write access to commit statuses in public and private repositories. This scope is only necessary to grant other users or services access to private repository commit statuses without granting access to the code. -
repo_deployment
– Grants access to deployment statuses for public and private repositories. This scope is only necessary to grant other users or services access to deployment statuses, without granting access to the code. -
public_repo
– Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories. -
repo:invite
– Grants accept/decline abilities for invitations to collaborate on a repository. This scope is only necessary to grant other users or services access to invites without granting access to the code. -
security_events
– Grants: read and write access to security events in the code scanning API. This scope is only necessary to grant other users or services access to security events without granting access to the code. -
read:org
– Read-only access to organization membership, organization projects, and team membership. -
user:email
– Grants read access to a user's email addresses. Required by Amazon Kendra to crawl ACLs. -
user:follow
– Grants access to follow or unfollow other users. Required by Amazon Kendra to crawl ACLs. -
read:user
– Grants access to read a user's profile data. Required by Amazon Kendra to crawl ACLs. -
workflow
– Grants the ability to add and update GitHub Actions workflow files. Workflow files can be committed without this scope if the same file (with both the same path and contents) exists on another branch in the same repository.
For more information, see Scopes for OAuth apps
in GitHub Docs. For GitHub Enterprise Server (On Prem)
-
repo:status
– Grants read/write access to commit statuses in public and private repositories. This scope is only necessary to grant other users or services access to private repository commit statuses without granting access to the code. -
repo_deployment
– Grants access to deployment statuses for public and private repositories. This scope is only necessary to grant other users or services access to deployment statuses, without granting access to the code. -
public_repo
– Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories. -
repo:invite
– Grants accept/decline abilities for invitations to collaborate on a repository. This scope is only necessary to grant other users or services access to invites without granting access to the code. -
security_events
– Grants: read and write access to security events in the code scanning API. This scope is only necessary to grant other users or services access to security events without granting access to the code. -
read:user
– Grants access to read a user's profile data. Required by Amazon Q Business to crawl ACLs. -
user:email
– Grants read access to a user's email addresses. Required by Amazon Q Business to crawl ACLs. -
user:follow
– Grants access to follow or unfollow other users. Required by Amazon Q Business to crawl ACLs. -
site_admin
– Grants site administrators access to GitHub Enterprise Server Administration API endpoints. -
workflow
– Grants the ability to add and update GitHub Actions workflow files. Workflow files can be committed without this scope if the same file (with both the same path and contents) exists on another branch in the same repository.
For more information, see Scopes for OAuth apps
in GitHub Docs and Understanding scopes for OAuth Apps in GitHub Developer. -
-
Checked each document is unique in GitHub and across other data sources you plan to use for the same index. Each data source that you want to use for an index must not contain the same document across the data sources. Document IDs are global to an index and must be unique per index.
In your AWS account, make sure you have:
-
Created an Amazon Kendra index and, if using the API, noted the index ID.
-
Created an IAM role for your data source and, if using the API, noted the ARN of the IAM role.
Note
If you change your authentication type and credentials, you must update your IAM role to access the correct AWS Secrets Manager secret ID.
-
Stored your GitHub authentication credentials in an AWS Secrets Manager secret and, if using the API, noted the ARN of the secret.
Note
We recommend that you regularly refresh or rotate your credentials and secret. Provide only the necessary access level for your own security. We do not recommend that you re-use credentials and secrets across data sources, and connector versions 1.0 and 2.0 (where applicable).
If you don’t have an existing IAM role or secret, you can use the console to create a new IAM role and Secrets Manager secret when you connect your GitHub data source to Amazon Kendra. If you are using the API, you must provide the ARN of an existing IAM role and Secrets Manager secret, and an index ID.
Connection instructions
To connect Amazon Kendra to your GitHub data source, you must provide the necessary details of your GitHub data source so that Amazon Kendra can access your data. If you have not yet configured GitHub for Amazon Kendra, see Prerequisites.
To connect Amazon Kendra to GitHub
-
Sign in to the AWS Management Console and open the Amazon Kendra console
. -
From the left navigation pane, choose Indexes and then choose the index you want to use from the list of indexes.
Note
You can choose to configure or edit your User access control settings under Index settings.
-
On the Getting started page, choose Add data source.
-
On the Add data source page, choose GitHub connector, and then choose Add connector. If using version 2 (if applicable), choose GitHub connector with the "V2.0" tag.
-
On the Specify data source details page, enter the following information:
-
In Name and description, for Data source name—Enter a name for your data source. You can include hyphens but not spaces.
-
(Optional) Description—Enter an optional description for your data source.
-
In Default language—Choose a language to filter your documents for the index. Unless you specify otherwise, the language defaults to English. Language specified in the document metadata overrides the selected language.
-
In Tags, for Add new tag—Include optional tags to search and filter your resources or track your AWS costs.
-
Choose Next.
-
-
On the Define access and security page, enter the following information:
-
GitHub source—Choose between GitHub Enterprise Cloud and GitHub Enterprise Server.
-
GitHub host URL—For example, the host URL for GitHub cloud could be
https://api.github.com
and the host URL for GitHub server could behttps://on-prem-host-url/api/v3/
. -
GitHub organization name—Enter your GitHub organization name. You can find your organization information in your GitHub account.
Note
GitHub connector supports crawling a single organization per data source connector instance.
-
Authorization—Turn on or off access control list (ACL) information for your documents, if you have an ACL and want to use it for access control. The ACL specifies which documents that users and groups can access. The ACL information is used to filter search results based on the user or their group access to documents. For more information, see User context filtering.
-
AWS Secrets Manager secret—Choose an existing secret or create a new Secrets Manager secret to store your GitHub authentication credentials. If you choose to create a new secret an AWS Secrets Manager secret window opens.
-
Enter following information in the Create an AWS Secrets Manager secret window:
-
Secret name—A name for your secret. The prefix ‘AmazonKendra-GitHub-’ is automatically added to your secret name.
-
For GitHub token—Enter the authentication credential value configured in GitHub.
-
-
Save and add your secret.
-
-
Virtual Private Cloud (VPC)—You can choose to use a VPC. If so, you must add Subnets and VPC security groups.
-
Identity crawler—Specify whether to turn on Amazon Kendra’s identity crawler. The identity crawler uses the access control list (ACL) information for your documents to filter search results based on the user or their group access to documents. If you have an ACL for your documents and choose to use your ACL, you can then also choose to turn on Amazon Kendra’s identity crawler to configure user context filtering of search results. Otherwise, if identity crawler is turned off, all documents can be publicly searched. If you want to use access control for your documents and identity crawler is turned off, you can alternatively use the PutPrincipalMapping API to upload user and group access information for user context filtering.
-
IAM role—Choose an existing IAM role or create a new IAM role to access your repository credentials and index content.
Note
IAM roles used for indexes cannot be used for data sources. If you are unsure if an existing role is used for an index or FAQ, choose Create a new role to avoid errors.
-
Choose Next.
-
-
On the Configure sync settings page, enter the following information:
-
Select repositories—Choose to crawl all repositories or select.
If you choose to crawl select repositories, add the names for the repositories and, optionally, the name of any specific branches.
-
Content types—Choose the content types you want to crawl from files, issues, pull requests, and more.
-
Regex patterns—Add regular expression patterns to include or exclude certain files.
-
Sync mode—Choose how you want to update your index when your data source content changes. When you sync your data source with Amazon Kendra for the first time, all content is crawled and indexed by default. You must run a full sync of your data if your initial sync failed, even if you don't choose full sync as your sync mode option.
-
Full sync: Freshly index all content, replacing existing content each time your data source syncs with your index.
-
New, modified sync: Index only new and modified content each time your data source syncs with your index. Amazon Kendra can use your data source's mechanism for tracking content changes and index content that changed since the last sync.
-
New, modified, deleted sync: Index only new, modified, and deleted content each time your data source syncs with your index. Amazon Kendra can use your data source's mechanism for tracking content changes and index content that changed since the last sync.
-
-
In Sync run schedule for Frequency—Choose how often to sync your data source content and update your index.
-
Choose Next.
-
-
On the Set field mappings page, enter the following information:
-
Default data source fields—Select from the Amazon Kendra generated default data source fields you want to map to your index.
-
Add field—To add custom data source fields to create an index field name to map to and the field data type.
-
Choose Next.
-
-
On the Review and create page, check that the information you have entered is correct and then select Add data source. You can also choose to edit your information from this page. Your data source will appear on the Data sources page after the data source has been added successfully.
Learn more
To learn more about integrating Amazon Kendra with your GitHub data source, see: