27 lines
1.2 KiB
Markdown
27 lines
1.2 KiB
Markdown
# 03 Project GitHub Repository Connections
|
|
|
|
## Goal
|
|
|
|
Allow projects to link one or more GitHub repositories through the existing project repository settings workflow.
|
|
|
|
## Requirements
|
|
|
|
- Reuse the existing repository connection model and project settings flow for GitHub.
|
|
- A GitHub repository connection must store enough data to identify the provider and repository.
|
|
- Repository linking must remain protected by the appropriate project-level permissions.
|
|
- The repository list must make the provider source clear when a project uses more than one Git provider.
|
|
- The design should allow a project to hold both Gitea and GitHub repository connections when supported by the underlying provider abstraction.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- An authorized user can add, edit, list, and remove GitHub repository connections for a project.
|
|
- A project can hold more than one GitHub repository connection.
|
|
- A project can display mixed-provider repository connections without ambiguity.
|
|
- The stored data remains compatible with the provider-neutral repository connection layer introduced in earlier releases.
|
|
|
|
## Out of Scope
|
|
|
|
- Cross-project shared repository connections
|
|
- Automatic background metadata refresh
|
|
- Organization-level permission management inside KanbanGit
|