feat: implement git repository management
- Add backend API for git repository CRUD (create, list, delete) - Support bare repository initialization and mirror cloning - Add cascade delete for repositories when project is deleted - Add frontend page for repository management per project - Update project page with link to repositories - Add repo_base_path to config - Quality gates: ruff, mypy, typecheck, lint, build all pass
This commit is contained in:
Fusion
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-05-18
|
||||
@@ -0,0 +1,51 @@
|
||||
## Context
|
||||
|
||||
The SSHKey model exists in the database but there's no API to create, list, or manage SSH keys. Users need SSH keys for git operations with external providers.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- Generate Ed25519 SSH key pairs via API
|
||||
- Encrypt private keys with Fernet before storage
|
||||
- List user's SSH keys with public key display
|
||||
- Support copying public keys to clipboard
|
||||
- Allow deletion of SSH keys
|
||||
|
||||
**Non-Goals:**
|
||||
- RSA key generation (Ed25519 only)
|
||||
- Private key display/decryption to users
|
||||
- SSH key editing (name changes only via update)
|
||||
- Integration with git operations (separate feature)
|
||||
|
||||
## Decisions
|
||||
|
||||
1. **Use cryptography library for key generation**
|
||||
- Ed25519 keys via `cryptography.hazmat.primitives.asymmetric.ed25519`
|
||||
- Fernet symmetric encryption for private keys
|
||||
- Already in project dependencies
|
||||
|
||||
2. **Store private keys encrypted**
|
||||
- Never expose private keys through API
|
||||
- Fernet key derived from application secret
|
||||
- One-way encryption, no decryption endpoint
|
||||
|
||||
3. **Frontend uses simple table/list view**
|
||||
- Name, created date, public key preview
|
||||
- Copy button for full public key
|
||||
- Generate and delete actions
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- **[Fernet key rotation loses access to old keys]** → Document that rotating JWT_SECRET effectively locks old SSH keys
|
||||
- **[Private key storage is only as secure as Fernet key]** → Store Fernet key securely, use strong application secret
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Create API endpoints
|
||||
2. Add frontend page
|
||||
3. Register router
|
||||
4. Run tests
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should we allow SSH key naming during generation?
|
||||
@@ -0,0 +1,25 @@
|
||||
## Why
|
||||
|
||||
SSH keys are required for git operations with external providers. Currently the SSHKey model exists but there's no API or UI to generate, manage, or use SSH keys.
|
||||
|
||||
## What Changes
|
||||
|
||||
- Add backend API endpoints for SSH key CRUD operations
|
||||
- Implement Ed25519 key generation with Fernet encryption for private keys
|
||||
- Add frontend page for SSH key management
|
||||
- Display public keys with copy functionality
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `ssh-key-management`: Generate and manage SSH keys for git operations
|
||||
|
||||
### Modified Capabilities
|
||||
- None
|
||||
|
||||
## Impact
|
||||
|
||||
- `apps/api/src/api/`: New ssh_keys.py router
|
||||
- `apps/api/src/models/ssh_key.py`: May need updates
|
||||
- `apps/web/src/`: New SSH keys page
|
||||
- `apps/api/src/main.py`: Register new router
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: SSH Key Generation
|
||||
|
||||
The system SHALL generate Ed25519 SSH key pairs and encrypt the private key with Fernet.
|
||||
|
||||
#### Scenario: Generate key
|
||||
- **WHEN** an authenticated user requests a new SSH key with a name
|
||||
- **THEN** an Ed25519 key pair is generated
|
||||
- **AND** the private key is encrypted with Fernet
|
||||
- **AND** the public key is stored in OpenSSH format
|
||||
- **AND** the key is associated with the user
|
||||
|
||||
### Requirement: SSH Key Listing
|
||||
|
||||
The system SHALL list all SSH keys for the authenticated user.
|
||||
|
||||
#### Scenario: List keys
|
||||
- **WHEN** an authenticated user views their SSH keys
|
||||
- **THEN** all their keys are listed with name, public key preview, and created date
|
||||
|
||||
### Requirement: SSH Key Display
|
||||
|
||||
The system SHALL display public keys for copying.
|
||||
|
||||
#### Scenario: Copy public key
|
||||
- **WHEN** an authenticated user views an SSH key
|
||||
- **THEN** the full public key is displayed in OpenSSH format
|
||||
- **AND** a copy-to-clipboard button is available
|
||||
|
||||
### Requirement: SSH Key Deletion
|
||||
|
||||
The system SHALL support key removal.
|
||||
|
||||
#### Scenario: Delete key
|
||||
- **WHEN** an authenticated user deletes an SSH key
|
||||
- **THEN** it's removed from the database
|
||||
- **AND** the key files are deleted if stored on disk
|
||||
@@ -0,0 +1,21 @@
|
||||
## 1. Backend SSH Key API
|
||||
|
||||
- [x] 1.1 Create `apps/api/src/api/ssh_keys.py` with endpoints for list, generate, and delete SSH keys.
|
||||
- [x] 1.2 Implement Ed25519 key generation using cryptography library.
|
||||
- [x] 1.3 Implement Fernet encryption for private keys.
|
||||
- [x] 1.4 Add Pydantic schemas for SSHKeyCreate, SSHKeyResponse.
|
||||
- [x] 1.5 Register ssh_keys router in `apps/api/src/main.py`.
|
||||
- [x] 1.6 Add backend tests for SSH key CRUD operations.
|
||||
|
||||
## 2. Frontend SSH Keys Page
|
||||
|
||||
- [x] 2.1 Create `apps/web/src/api/ssh_keys.ts` with API methods.
|
||||
- [x] 2.2 Create `apps/web/src/pages/ssh-keys.tsx` with key list, generate form, and delete action.
|
||||
- [x] 2.3 Add `/ssh-keys` route in `apps/web/src/router.tsx`.
|
||||
- [x] 2.4 Update app shell navigation to include SSH keys link.
|
||||
|
||||
## 3. Verification
|
||||
|
||||
- [x] 3.1 Run backend checks (pytest, ruff, mypy).
|
||||
- [x] 3.2 Run frontend checks (npm test, typecheck, lint, build).
|
||||
- [x] 3.3 Update tasks file with completed checkboxes.
|
||||
@@ -0,0 +1,2 @@
|
||||
schema: spec-driven
|
||||
created: 2026-05-18
|
||||
@@ -0,0 +1,61 @@
|
||||
## Context
|
||||
|
||||
Current test infrastructure has ~50 backend tests and 12 frontend tests. Backend tests are mixed in a single directory with inconsistent patterns. Some tests require a running PostgreSQL instance even when testing pure logic. There's no E2E test coverage.
|
||||
|
||||
## Goals / Non-Goals
|
||||
|
||||
**Goals:**
|
||||
- Separate tests into unit/integration/system categories with clear boundaries.
|
||||
- Create shared fixtures to eliminate duplication.
|
||||
- Enable fast unit tests without PostgreSQL (SQLite in-memory).
|
||||
- Implement proper transaction isolation for integration tests.
|
||||
- Add E2E tests for critical user journeys (login, project creation).
|
||||
- Make tests runnable both locally and in Docker.
|
||||
|
||||
**Non-Goals:**
|
||||
- Rewriting all existing tests (restructure and migrate gradually).
|
||||
- Adding tests for features that don't exist yet.
|
||||
- Complex test parallelization setup.
|
||||
- Performance benchmarking.
|
||||
|
||||
## Decisions
|
||||
|
||||
1. **Use SQLite for unit tests, PostgreSQL for integration/system tests**
|
||||
- Rationale: Unit tests should be fast and not require external services.
|
||||
- SQLite runs in-memory, no Docker needed.
|
||||
|
||||
2. **Use `pytest-asyncio` with `asyncio_mode=auto`**
|
||||
- Rationale: Simplifies test writing, no need for `@pytest.mark.asyncio` on every test.
|
||||
|
||||
3. **Shared `conftest.py` with session-scoped engine**
|
||||
- Rationale: Eliminates duplicate engine creation across files.
|
||||
- Integration tests use `begin_nested()` for transaction rollback.
|
||||
|
||||
4. **Directory structure: `tests/unit/`, `tests/integration/`, `tests/system/`**
|
||||
- Rationale: Clear separation, easy to run selectively.
|
||||
- `pytest -m unit` runs all unit tests regardless of location.
|
||||
|
||||
5. **Playwright for E2E tests**
|
||||
- Rationale: Modern, well-supported, works with React/Vite.
|
||||
- Tests run against the actual deployed application.
|
||||
|
||||
## Risks / Trade-offs
|
||||
|
||||
- **[SQLite vs PostgreSQL behavior differences]** -> Document known differences (e.g., JSON operators, asyncpg-specific features).
|
||||
- **[Migration effort for existing tests]** -> Migrate gradually, prioritize new tests over rewriting old ones.
|
||||
- **[E2E tests are slower]** -> Run them selectively (not on every commit), maybe only in CI or nightly.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
1. Create new directory structure.
|
||||
2. Implement shared fixtures in `conftest.py`.
|
||||
3. Add SQLite support for unit tests.
|
||||
4. Migrate 2-3 existing tests as examples.
|
||||
5. Add Playwright setup and 1-2 E2E tests.
|
||||
6. Update Makefile targets.
|
||||
7. Document testing strategy.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should we use `pytest-xdist` for parallel test execution?
|
||||
- Should E2E tests run against the Docker compose setup or a staging environment?
|
||||
@@ -0,0 +1,41 @@
|
||||
## Why
|
||||
|
||||
The current test infrastructure has several issues that slow development and reduce confidence:
|
||||
|
||||
1. **Mixed test types in single directory**: Unit, integration, and system tests are all mixed together in `apps/api/tests/`, making it hard to run fast unit tests independently.
|
||||
2. **Duplicate fixture code**: Database setup/teardown is duplicated across multiple test files instead of using a shared `conftest.py`.
|
||||
3. **Inconsistent test patterns**: 4 different patterns exist for database setup (sync helpers, async fixtures, module reloads, autouse env vars).
|
||||
4. **No test database isolation**: Tests truncate tables manually instead of using transaction rollback, leading to potential data leakage.
|
||||
5. **Backend tests require live PostgreSQL**: Unit tests that test pure logic still connect to a real database.
|
||||
6. **No E2E/system tests**: There's no automated way to test the full stack (frontend + API + database) together.
|
||||
7. **Import errors in local environment**: Tests depend on packages not in `dev` dependencies (e.g., `python-jose`).
|
||||
|
||||
## What Changes
|
||||
|
||||
- **Restructure backend tests** into `unit/`, `integration/`, and `system/` directories.
|
||||
- **Create shared fixtures** in `conftest.py` for database sessions, test client, and authentication.
|
||||
- **Add SQLite in-memory support** for fast unit tests that don't need PostgreSQL.
|
||||
- **Implement transaction rollback isolation** using `begin_nested()` for integration tests.
|
||||
- **Add missing test dependencies** to `pyproject.toml`.
|
||||
- **Create E2E test setup** using Playwright for critical user journeys.
|
||||
- **Add test markers** (`@pytest.mark.unit`, `@pytest.mark.integration`, `@pytest.mark.system`) to enable selective test runs.
|
||||
- **Update Makefile** with `test-unit`, `test-integration`, `test-system`, and `test-e2e` targets.
|
||||
|
||||
## Capabilities
|
||||
|
||||
### New Capabilities
|
||||
- `test-organization`: Structured test directories with clear separation of concerns.
|
||||
- `test-isolation`: Transaction rollback and SQLite support for fast, isolated tests.
|
||||
- `e2e-testing`: Playwright-based end-to-end tests for critical user journeys.
|
||||
|
||||
### Modified Capabilities
|
||||
- `docker-infrastructure`: Add test database service and test runner configuration.
|
||||
|
||||
## Impact
|
||||
|
||||
- `apps/api/tests/`: Restructured into subdirectories.
|
||||
- `apps/api/pyproject.toml`: New test dependencies added.
|
||||
- `apps/api/conftest.py`: New shared fixtures file.
|
||||
- `Makefile`: New test targets.
|
||||
- New `e2e/` directory for Playwright tests.
|
||||
- CI pipeline may need updates to run new test categories.
|
||||
+35
@@ -0,0 +1,35 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: E2E Test Framework
|
||||
|
||||
The system SHALL provide end-to-end tests using Playwright.
|
||||
|
||||
#### Scenario: Test setup
|
||||
- GIVEN the e2e test directory
|
||||
- THEN `e2e/` SHALL contain Playwright configuration
|
||||
- AND tests SHALL run against the full application stack
|
||||
|
||||
#### Scenario: Critical user journeys
|
||||
- GIVEN the e2e test suite
|
||||
- THEN it SHALL test:
|
||||
- User login flow
|
||||
- Project creation and listing
|
||||
- SSH key generation
|
||||
|
||||
#### Scenario: Test environment
|
||||
- GIVEN e2e tests are running
|
||||
- THEN they SHALL use a dedicated test database
|
||||
- AND tests SHALL clean up data after completion
|
||||
|
||||
### Requirement: Test Commands
|
||||
|
||||
The system SHALL provide Makefile targets for running different test categories.
|
||||
|
||||
#### Scenario: Make targets
|
||||
- GIVEN the Makefile
|
||||
- THEN these targets SHALL exist:
|
||||
- `make test-unit` - Run unit tests only
|
||||
- `make test-integration` - Run integration tests only
|
||||
- `make test-system` - Run system tests only
|
||||
- `make test-e2e` - Run Playwright E2E tests
|
||||
- `make test` - Run all backend tests
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Shared Test Fixtures
|
||||
|
||||
The system SHALL provide shared fixtures in `conftest.py` for common test needs.
|
||||
|
||||
#### Scenario: Database session fixture
|
||||
- GIVEN an integration test
|
||||
- WHEN using the `db_session` fixture
|
||||
- THEN it SHALL provide an async SQLAlchemy session
|
||||
- AND the session SHALL use transaction rollback for isolation
|
||||
|
||||
#### Scenario: Test client fixture
|
||||
- GIVEN an API integration test
|
||||
- WHEN using the `client` fixture
|
||||
- THEN it SHALL provide an authenticated TestClient instance
|
||||
- AND the client SHALL have valid access and refresh tokens
|
||||
|
||||
#### Scenario: SQLite unit test database
|
||||
- GIVEN a unit test
|
||||
- WHEN the test uses the `db_engine` fixture
|
||||
- THEN it SHALL provide an in-memory SQLite engine
|
||||
- AND no PostgreSQL connection SHALL be required
|
||||
|
||||
### Requirement: Transaction Isolation
|
||||
|
||||
The system SHALL ensure integration tests don't pollute the database.
|
||||
|
||||
#### Scenario: Rollback after test
|
||||
- GIVEN an integration test creates data
|
||||
- WHEN the test completes
|
||||
- THEN all database changes SHALL be rolled back
|
||||
- AND subsequent tests SHALL see a clean database state
|
||||
|
||||
#### Scenario: Parallel test safety
|
||||
- GIVEN multiple integration tests run concurrently
|
||||
- WHEN each test uses transaction isolation
|
||||
- THEN tests SHALL not interfere with each other
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Test Directory Structure
|
||||
|
||||
The system SHALL organize tests into unit, integration, and system directories.
|
||||
|
||||
#### Scenario: Directory layout
|
||||
- GIVEN the backend test suite
|
||||
- THEN `apps/api/tests/` SHALL contain:
|
||||
- `unit/` - Pure logic tests with no external dependencies
|
||||
- `integration/` - API endpoint tests with database
|
||||
- `system/` - Full stack tests with external services
|
||||
|
||||
#### Scenario: Running selective tests
|
||||
- GIVEN the test suite is organized
|
||||
- WHEN running `pytest -m unit`
|
||||
- THEN only unit tests SHALL execute
|
||||
- AND WHEN running `pytest -m integration`
|
||||
- THEN only integration tests SHALL execute
|
||||
|
||||
### Requirement: Test Markers
|
||||
|
||||
The system SHALL provide pytest markers for each test category.
|
||||
|
||||
#### Scenario: Marker registration
|
||||
- GIVEN pytest configuration
|
||||
- THEN `pyproject.toml` SHALL register markers:
|
||||
- `unit` - Fast tests with no external dependencies
|
||||
- `integration` - Tests with database and external services
|
||||
- `system` - End-to-end tests of the full stack
|
||||
|
||||
#### Scenario: Marker usage
|
||||
- GIVEN a test file
|
||||
- THEN unit tests SHALL be marked with `@pytest.mark.unit`
|
||||
- AND integration tests SHALL be marked with `@pytest.mark.integration`
|
||||
- AND system tests SHALL be marked with `@pytest.mark.system`
|
||||
@@ -0,0 +1,52 @@
|
||||
## 1. Restructure backend tests
|
||||
|
||||
- [x] 1.1 Create `apps/api/tests/unit/` directory and move pure logic tests
|
||||
- [x] 1.2 Create `apps/api/tests/integration/` directory and move API tests
|
||||
- [x] 1.3 Create `apps/api/tests/system/` directory for full stack tests
|
||||
- [x] 1.4 Update `pytest.ini` or `pyproject.toml` with test markers
|
||||
|
||||
## 2. Create shared fixtures
|
||||
|
||||
- [x] 2.1 Create `apps/api/tests/conftest.py` with shared fixtures
|
||||
- [x] 2.2 Implement SQLite in-memory engine fixture for unit tests
|
||||
- [x] 2.3 Implement PostgreSQL session fixture with transaction rollback
|
||||
- [x] 2.4 Implement authenticated TestClient fixture
|
||||
- [x] 2.5 Remove duplicate fixture code from existing test files
|
||||
|
||||
## 3. Add SQLite support for unit tests
|
||||
|
||||
- [x] 3.1 Add `aiosqlite` dependency to `pyproject.toml`
|
||||
- [x] 3.2 Update SQLAlchemy configuration to support SQLite
|
||||
- [x] 3.3 Verify unit tests run without PostgreSQL
|
||||
|
||||
## 4. Update dependencies and configuration
|
||||
|
||||
- [x] 4.1 Add missing test dependencies (`python-jose[cryptography]`)
|
||||
- [x] 4.2 Configure `pytest-asyncio` with `asyncio_mode=auto`
|
||||
- [x] 4.3 Add `addopts = -m "not system"` to default test run
|
||||
|
||||
## 5. Create E2E test setup
|
||||
|
||||
- [x] 5.1 Initialize Playwright in `e2e/` directory
|
||||
- [x] 5.2 Add Playwright configuration (`playwright.config.ts`)
|
||||
- [x] 5.3 Create first E2E test (login flow)
|
||||
- [x] 5.4 Add `make test-e2e` target to Makefile
|
||||
|
||||
## 6. Update Makefile
|
||||
|
||||
- [x] 6.1 Add `test-unit` target
|
||||
- [x] 6.2 Add `test-integration` target
|
||||
- [x] 6.3 Add `test-system` target
|
||||
- [x] 6.4 Update `test` target to run all categories
|
||||
|
||||
## 7. Migrate existing tests as examples
|
||||
|
||||
- [x] 7.1 Migrate `test_config.py` to `tests/unit/`
|
||||
- [x] 7.2 Migrate `test_auth_api.py` to `tests/integration/`
|
||||
- [x] 7.3 Verify migrated tests still pass
|
||||
|
||||
## 8. Documentation
|
||||
|
||||
- [x] 8.1 Update README with testing strategy
|
||||
- [x] 8.2 Document how to run specific test categories
|
||||
- [x] 8.3 Document fixture usage patterns
|
||||
Reference in New Issue
Block a user