103 lines
4.8 KiB
Markdown
103 lines
4.8 KiB
Markdown
# Implementation Plan: Git Integration Plugin for Dashboard Development
|
|
|
|
**Branch**: `011-git-integration-dashboard` | **Date**: 2026-01-22 | **Spec**: [spec.md](specs/011-git-integration-dashboard/spec.md)
|
|
**Input**: Feature specification from `/specs/011-git-integration-dashboard/spec.md`
|
|
|
|
## Summary
|
|
|
|
Implement a Git integration plugin that allows dashboard developers to version control their Superset dashboards. The plugin will support GitLab, GitHub, and Gitea, enabling branch management, committing/pushing changes (as unpacked Superset exports), and deploying to target environments via the Superset API.
|
|
|
|
## Technical Context
|
|
|
|
**Language/Version**: Python 3.9+ (Backend), Node.js 18+ (Frontend)
|
|
**Primary Dependencies**: FastAPI, SvelteKit, GitPython (or CLI git), Pydantic, SQLAlchemy, Superset API
|
|
**Storage**: SQLite (for config/history), Filesystem (local Git repositories)
|
|
**Testing**: pytest (Backend), SvelteKit testing utilities (Frontend)
|
|
**Target Platform**: Linux server
|
|
**Project Type**: Web application (Frontend + Backend)
|
|
**Performance Goals**: Branch switching < 5s, Search/Filter history < 2s
|
|
**Constraints**: Offline mode support, Superset API dependency for deployment, PAT-based authentication
|
|
**Scale/Scope**: 1 repository per dashboard, support for up to 1000 commits per repo
|
|
|
|
## Constitution Check
|
|
|
|
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
|
|
|
|
1. **Semantic Protocol Compliance**: All new modules must include headers, `[DEF]` anchors, and `@RELATION` tags as per `semantic_protocol.md`.
|
|
2. **Causal Validity**: API contracts and data models must be defined in `specs/` before implementation.
|
|
3. **Everything is a Plugin**: The Git integration must be implemented as a `PluginBase` subclass in `backend/src/plugins/`.
|
|
4. **Design by Contract**: Use Pydantic models for request/response validation and internal state transitions.
|
|
|
|
## Project Structure
|
|
|
|
### Documentation (this feature)
|
|
|
|
```text
|
|
specs/[###-feature]/
|
|
├── plan.md # This file (/speckit.plan command output)
|
|
├── research.md # Phase 0 output (/speckit.plan command)
|
|
├── data-model.md # Phase 1 output (/speckit.plan command)
|
|
├── quickstart.md # Phase 1 output (/speckit.plan command)
|
|
├── contracts/ # Phase 1 output (/speckit.plan command)
|
|
└── tasks.md # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)
|
|
```
|
|
|
|
### Source Code (repository root)
|
|
<!--
|
|
ACTION REQUIRED: Replace the placeholder tree below with the concrete layout
|
|
for this feature. Delete unused options and expand the chosen structure with
|
|
real paths (e.g., apps/admin, packages/something). The delivered plan must
|
|
not include Option labels.
|
|
-->
|
|
|
|
```text
|
|
backend/
|
|
├── src/
|
|
│ ├── api/routes/git.py # Git integration endpoints
|
|
│ ├── models/git.py # Git-specific Pydantic/SQLAlchemy models
|
|
│ ├── plugins/git_plugin.py # PluginBase implementation
|
|
│ └── services/git_service.py # Core Git logic (GitPython wrapper)
|
|
└── tests/
|
|
└── plugins/test_git.py
|
|
|
|
frontend/
|
|
├── src/
|
|
│ ├── components/git/ # Git UI components (BranchSelector, CommitModal, ConflictResolver)
|
|
│ ├── routes/settings/git/ # Git configuration pages
|
|
│ └── services/gitService.js # API client for Git operations
|
|
└── tests/
|
|
|
|
**Structure Decision**: Web application structure as the project has both FastAPI backend and SvelteKit frontend.
|
|
|
|
## Complexity Tracking
|
|
|
|
> **Fill ONLY if Constitution Check has violations that must be justified**
|
|
|
|
| Violation | Why Needed | Simpler Alternative Rejected Because |
|
|
|-----------|------------|-------------------------------------|
|
|
| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
|
|
[e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |
|
|
|
|
## Implementation Phases
|
|
|
|
### Phase 2: Backend Implementation (Plugin & Service)
|
|
1. **Git Service**: Implement `GitService` using `GitPython`. Focus on:
|
|
* Repo initialization and cloning.
|
|
* Branch management (list, create, checkout).
|
|
* Stage, commit, push, pull.
|
|
2. **Git Plugin**: Implement `GitPlugin(PluginBase)`.
|
|
* Integrate with `superset_tool` for exporting/importing dashboards.
|
|
* Handle unpacking ZIP exports into the repo structure.
|
|
3. **API Routes**: Implement `/api/git/*` endpoints.
|
|
|
|
### Phase 3: Frontend Implementation
|
|
1. **Configuration UI**: Settings page for `GitServerConfig`.
|
|
2. **Dashboard Integration**: Add Git controls to the Dashboard view.
|
|
* Branch selector.
|
|
* Commit/Push/Pull buttons.
|
|
3. **Conflict Resolution UI**: Implementation of "Keep Mine/Theirs" file picker.
|
|
|
|
### Phase 4: Deployment Integration
|
|
1. **Environment Management**: CRUD for `DeploymentEnvironment`.
|
|
2. **Deployment Logic**: Trigger Superset Import API on target servers.
|