Skip to content

feat: Add support for personal access tokens in GitHub integration - #31

Merged
pikann merged 2 commits into
masterfrom
feature/add-support-for-pat
Oct 28, 2026
Merged

pikann merged 2 commits into
masterfrom
feature/add-support-for-pat

Conversation

@pikann

@pikann pikann commented Oct 28, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Turns the plugin into the GitHub provider for Paca's Git provider SPI (gitprovider.v1) and gives it two ways to connect: a GitHub App (manifest flow) or a personal access token. Paca core now owns repositories, pull requests, task links, triggers, runs and the UI; this plugin only answers GitHub-specific questions.

Needs Paca core with the Git integration (minCoreVersion v0.20.0), and builds against plugin-sdk-go v0.4.1.

What changed

Provider (backend/spi_*.go)

  • Implements the whole SPI: identity setup, repository resolution and listing, credentials, webhook verification and normalisation, policy inputs (actor permission, branch protection), reads (change requests, files, diffs, threads, comments, issues, checks and logs), writes (open/update change requests, comments, replies, batch reviews, status) and the optional operations: thread resolution, file read, labels, reviewers, assignees, merge, branches, identity deletion, access grants and webhook management.
  • Declares capabilities.kinds: the App is ephemeral with an app-level webhook and needs an installation per account; the token is static with a webhook per repository and needs no installation.
  • Passes the SDK conformance suite (App fixtures) against a fake GitHub.

GitHub App connection

  • Created through the manifest flow, with the webhook pointing at Paca core. The App is installed per account when a project links a repository there (access grants), and installations are discovered lazily from GitHub.
  • Credentials are installation tokens narrowed to one repository and to contents read or write; the webhook secret and private key are stored encrypted.

Personal access token connection (spi_token.go)

  • Setup is a one-field form: the token is validated against GET /user, its expiry is kept when GitHub reports one, and a mistyped token does not spend the setup state.
  • Credentials are static and never handed to an agent. Events arrive through a webhook registered on each linked repository with a generated secret (EnsureWebhook is idempotent for the same URL; RemoveWebhook tolerates one that is already gone); the token needs the webhook permission.
  • A token cannot create check runs, so run status is reported as commit statuses.
  • Review requests and assignments are recognised by the token owner's login (no [bot] suffix).

Data

  • 0002_git_provider.sql creates github_apps, github_app_installations, github_tokens and github_manifest_sessions (with the setup kind).
  • It migrates the previous release's data into core and drops the old tables: each project's access token becomes a project-scoped token connection (ciphertext copied as is, so the same ENCRYPTION_KEY must be in place) with its linked repositories, branch links and pull request links. The owner's login and a webhook secret are not known to the migration; both are filled in the first time the token is used. Webhooks the old release registered point at the old plugin and are left on GitHub (use "Try again" on each repository to register a new one).
  • Verified on a throwaway Postgres with sample data, and for a fresh install with no old rows.

Removed

  • The old project-bound integration, its routes, the settings/task frontend, the MCP server, the workflow skill and the related CI workflows: all of that now lives in Paca core (git_* tables, the Git settings UI, the Git MCP tools).

Upgrading

See the README ("Upgrading from 0.4.x"). Existing project tokens keep working as project connections; add Apps from a project's Settings → Git → Connections.

Test plan

  • go vet and go test in backend/ (SDK conformance suite, fake GitHub, token flow, webhook parsing, store tests)
  • Migration 0002 applied on Postgres 16 with old data (tokens, repositories, pull request and branch links) and on a fresh schema
  • Build the .wasm with tinygo and install it in a Paca instance
  • Manual against real GitHub: create an App and install it on an account; add a token; link repositories through each; check webhook registration and commit statuses
  • Migrate a real database that holds an old project token

🤖 Generated with Claude Code

- Introduced `tokenRecord` struct to manage personal access token identities.
- Updated `spiStore` interface to include methods for loading, creating, updating, and deleting tokens.
- Enhanced `ghProvider` to handle token identities, including setup, webhook management, and repository access.
- Implemented webhook verification for token identities, ensuring proper handling of events.
- Updated tests to cover new token functionality, including setup, credential minting, and webhook management.
- Modified plugin description to reflect support for both GitHub App and personal access token connections.
@pikann
pikann merged commit 749fe27 into master Oct 28, 2026
3 checks passed
@pikann
pikann deleted the feature/add-support-for-pat branch October 28, 2026 12:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant