GitHub Sensor

What it ingests

Repository activity — issues, pull requests, commits, review summaries, and comment threads (issue comments, PR conversation comments, and line-level review comments) — across a single organization or an explicit list of repositories.

Comments arrive from the same Events API poll as everything else (zero extra requests). That feed is capped at a few hundred events and roughly 90 days, so older thread history is not ingested. Review summaries stay on PullRequestReviewEvent; line comments are additive.

Credential

The GitHub source references a github_token credential by id. Create one with a Personal Access Token that has read access to the org/repos you want to ingest:

• Classic PAT — repo scope (or public_repo for public repos only) and read:org.
• Fine-grained PAT — repository permissions: read-only Contents, Issues, Pull requests, and Metadata on the target repositories; plus organization permission Events (organization_events: read). Include the org/repos in the token's repository access list. A missing permission surfaces as a 403 naming the permission that's absent.

Those extra scopes (read:org / organization_events) are required because the source polls the GitHub Events/Activity API for org/repo activity and comment threads — the same poll described above. Without them the poll returns 403 Resource not accessible by personal access token.

curl -sS -X POST https://your-corveil-host/api/credentials \
  -H "Authorization: Bearer <admin>" -H "Content-Type: application/json" \
  -d '{"type":"github_token","name":"acme-github-ro","secret":"ghp_..."}'

Copy the returned credential id.

Config fields

Key	Required	Notes
org	one of org / repos	Organization login, e.g. radiusmethod.
repos	one of org / repos	Comma-separated owner/name list, e.g. acme/api, acme/web.

Provide either an organization or an explicit repo list (or both).

Provider-side setup

1. Create the PAT at GitHub → Settings → Developer settings → Personal access tokens.
2. Grant the scopes in Credential above, including Events / read:org, and add the org or repositories to the token's access list.
3. If the org enforces SSO, authorize the token for the org.

Wire-up

POST /api/sensors

{
  "sensor_type": "github",
  "name": "Acme GitHub",
  "config": { "org": "acme" },
  "credentials": { "token": "<github_token credential id>" }
}

To scope to specific repos instead:

{
  "sensor_type": "github",
  "name": "Acme API + Web",
  "config": { "repos": "acme/api, acme/web" },
  "credentials": { "token": "<github_token credential id>" }
}

What lands in the ontology

The source stamps a signal on every event; the default bindings map each one to an entity type. You can preview and edit these on the Add sensor form and change them later in the source's bindings drawer.

Signal	Entity	Notes
push	Repository, Organization	The repo, and the GitHub owner as the Organization
pull_request	PullRequest	Named owner/repo#12
issue	Issue	Named owner/repo#7
commit	Commit	From the backfill
issue_comment	Comment	Issue comments and PR conversation comments. Person AUTHORED Comment, Comment RELATED_TO the parent Issue or PullRequest
review_comment	Comment	Line-level review comments, related to the PullRequest. Separate from the review-summary signal so you can disable one without the other
pull_request_review	(edge only)	Person REVIEWED / APPROVED the PullRequest. No Comment entity — that is the review summary, not a thread comment

People are resolved from the actor on each event and deduplicated against identities from your other sources.

Comments are keyed by GitHub comment id, so a re-poll does not duplicate. An edited comment does not overwrite the stored body (ON CONFLICT DO NOTHING).

Verify

Use Test connection on the source (or watch the first poll). A healthy source reports events flowing; a credential problem surfaces as an auth failure with the missing scope/permission named.