Oracus.ai uses GitHub as the source of truth for who works on what. Once connected, every answer can name the engineer who built a feature and the team they’re on — not just a generic “the engineering team owns this.”
This integration is read-only and people-only: it pulls org members, teams, memberships, and a few metadata fields. No code is ingested through this connector — that comes from the git repository connector, which is separate.
What gets synced
| From GitHub | Mirrored as | Used for |
|---|---|---|
| Org members | User rows (login, name, email, avatar URL) | Resolving @mentions and Jira assignees to a real person |
| Teams (incl. nested) | Team rows (org, slug, parent, privacy) | Surfacing team ownership in citations |
| Team memberships | TeamMembership rows with role (member / maintainer) | “Who can I ask?” and tech-lead detection |
Each table tracks lastSyncedAt so stale records are obvious in the admin UI.
Setup
You can authenticate with either a personal access token (PAT) or a GitHub App installation. PAT is faster for a first install; App is the right answer for production.
Option 1: Personal access token
- Go to GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens.
- Create a token scoped to your organization.
- Grant read-only access to:
- Organization → Members: Read
- In Oracus.ai → Settings → GitHub, paste the token and the org login (e.g.
oracus-ai).
The token is encrypted at rest with your ENCRYPTION_KEY before being stored.
Option 2: GitHub App
- Create a private GitHub App under your org’s developer settings.
- Grant the app these read-only permissions:
- Organization permissions → Members: Read
- Install the app on your org, note the App ID and the installation ID.
- In Oracus.ai → Settings → GitHub, enter the App ID and installation ID and upload the private key.
App-based auth doesn’t expire on user rotation and is what most security teams prefer.
How ownership matching works
Once the GitHub data is mirrored, Oracus.ai joins it onto Jira and code-review signals:
- Jira assignees and reporters are matched to GitHub users by login (fall-through to email when login isn’t set on the Jira account).
- Git repository teams (the
teamon aSourceRepo) are matched to GitHub teams by slug, so questions scoped to a repo can name the owning team. - Ownership confidence improves when the same person shows up on both sides — e.g. assigned the Jira ticket and listed in the right GitHub team. Citations prefer the cross-referenced answer.
You can override the join manually in the admin UI for any user whose Jira and GitHub identifiers don’t align.
Re-sync cadence
The integration runs:
- On connect — full sync of teams + members + memberships.
- Hourly — incremental sync of the same surfaces.
- On demand — click Sync now on the Settings page when you’ve just changed team membership and want it reflected immediately.
lastSyncedAt on the GithubIntegration row tells you when the last successful run finished. syncStatus and syncError surface in the admin UI if a sync fails.
What’s not pulled
This connector covers people and ownership. Other GitHub surfaces are deliberately separated:
| Surface | Where it lives |
|---|---|
| Code, READMEs, specs, dependency maps | Git repository connector — clones the repo and runs spec-gen |
| PR descriptions, reviews, comments | Not yet ingested. On the v1.1 roadmap. |
| Issues | Not ingested. Use Jira for issue tracking. |
| Workflow runs / CI status | Not ingested. Use the JUnit ingest path. |
Splitting these keeps the GitHub people-sync narrow and the required permissions minimal — easier to get past security review.
FAQ
Can I use it without a Jira connection? Yes. You still get “who’s on the Payments team?” answers — they just won’t carry Jira ticket context until you connect Jira too.
Does Oracus.ai write back to GitHub? No. The integration is read-only. There is no scope, App permission, or code path that mutates anything in your GitHub org.
What happens when someone leaves the org?
They’ll disappear from TeamMembership on the next sync. Their User row stays so historical citations (closed Jira tickets, old PRs) still resolve to a name; you can hard-delete it manually if needed.