Filing issues to GitHub or GitLab
Connecting a tracker, what goes into a draft, and the guards against duplicate filings.
Integrations are how the agent reads your systems. Issue trackers are how a finished triage leaves Triagic.
Connecting a tracker
On the desktop Integrations page, under Issue trackers → Connect tracker, paste a personal access token.
| Provider | Token scope | Self-managed |
|---|---|---|
| GitHub | Classic: repo. Fine-grained: Issues: Read and write + Metadata: Read-only, with the target repositories selected. | Set Host to your GitHub Enterprise Server URL; the /api/v3 root is derived. |
| GitLab | api. (read_api can list projects but cannot create issues.) Reporter or above on the project. | Set Host to your instance URL; /api/v4 is derived. |
Tokens are per user — yours, not your organization's — encrypted at rest with the same AES-256-GCM key as everything else, and never returned by the API.
Saving verifies the token first. If the provider rejects it, nothing is stored, so a bad token cannot sit around until the first time someone tries to file. The connected account is shown on the card once it works.
Filing an issue
Create issue appears on any finished Console answer and in a ticket's AI Investigation header.
The dialog is draft-first: Triagic assembles a draft from what it already has — summary, root cause, evidence, funnel drop-off, tools queried, and a link back to the ticket or thread — and you edit it before anything is posted. What you see is exactly what gets created.
You pick:
- Repository / project — type-ahead over what your token can see, or paste
owner/repodirectly. The last one you used per tracker is remembered. - Labels and assignees — pulled live from that project.
Duplicate filings need an explicit confirmation
Issues already filed from the same triage are listed at the top of the dialog, and filing another requires you to confirm. This is what stops two people raising the same incident twice.
What is deliberately left out
The reporter's email and user id are not included in the generated body. An engineering tracker usually has a wider audience than the support console, and identity fields are not what makes an issue actionable. Merchant and store names stay, because those are what an engineer needs to reproduce.
Afterwards
Created issues are recorded and shown as Linked issues on the ticket. That row survives disconnecting the tracker — the issue still exists upstream, so the link should still work.
Permissions and audit
Drafts and filings are provenance-checked: you cannot draft from a ticket you cannot already read, or from someone else's Console thread.
Every filing writes an issue.create audit entry with provider, project, issue key,
labels and source. Connecting and disconnecting a tracker write their own entries.