33 lines
1.3 KiB
Markdown
33 lines
1.3 KiB
Markdown
# 01 GitHub Provider Foundation and Auth Strategy
|
|
|
|
## Goal
|
|
|
|
Introduce GitHub as the second concrete Git provider behind the existing provider abstraction while keeping the first GitHub auth mode aligned with KanbanGit's current per-user connection model.
|
|
|
|
## Requirements
|
|
|
|
- Add GitHub as a supported provider key and provider client.
|
|
- Target GitHub Cloud on `https://api.github.com`.
|
|
- Keep project, ticket, and repository-connection core logic free from GitHub-specific assumptions wherever possible.
|
|
- The provider client must support the API surface needed for:
|
|
- authenticated user metadata
|
|
- repository listing
|
|
- repository lookup
|
|
- branch listing
|
|
- pull request listing
|
|
- The release must choose one initial GitHub auth strategy and document it clearly.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- The codebase has a clear GitHub provider implementation behind the existing provider boundary.
|
|
- GitHub-specific HTTP details do not leak into ticket or project core logic.
|
|
- The selected GitHub auth strategy is compatible with the current `UserGitConnection` concept.
|
|
- The provider foundation is sufficient for later repository linking, branch discovery, and pull request visibility tickets in release `0.3`.
|
|
|
|
## Out of Scope
|
|
|
|
- GitHub App JWT handling
|
|
- GitHub installation tokens
|
|
- GitHub Enterprise Server support
|
|
- Webhook processing
|