- Delete E2E workflows and test files
- Remove multi-model demo example
- Update Postgres migration unit tests
- Enforce workspace requirement in tests
- Fix dimension mismatch test mocks
- Set Monday 2AM for GitHub Actions
- Set Wednesday 2AM for Python deps
- Set Friday 2AM for web UI deps
- Use Asia/Shanghai timezone
- Spread updates across weekdays
Why this change is needed:
Previous wait strategy used `/health` endpoint with `-f` flag and only
30 second timeout, causing timeouts in GitHub Actions.
How it solves it:
- Use root endpoint `/` instead of `/health` (Qdrant API root responds)
- Remove `-f` flag to accept any response (not just 2xx)
- Increase timeout from 30s to 60s
- Add progress output for each attempt
- Add clear error message on failure
Impact:
More reliable Qdrant service detection in E2E tests
Testing:
Will verify on GitHub Actions E2E test run
Why this change is needed:
E2E tests were failing with:
"ValueError: Storage implementation 'PGKVStorage' requires the following
environment variables: POSTGRES_DATABASE"
The workflow was setting POSTGRES_DB but LightRAG's check_storage_env_vars()
expects POSTGRES_DATABASE (matching ClientManager.get_config()).
How it solves it:
Changed environment variable name from POSTGRES_DB to POSTGRES_DATABASE
in the "Run PostgreSQL E2E tests" step.
Impact:
- PGKVStorage, PGGraphStorage, and PGDocStatusStorage can now properly
initialize using ClientManager's configuration
- Fixes ValueError during LightRAG initialization
Testing:
Next E2E run should pass environment variable validation and proceed
to actual test execution.
Why this change is needed:
Qdrant Docker image does not have curl or wget pre-installed,
causing health check to always fail and container to be marked
as unhealthy after timeout.
How it solves it:
Remove health check from Qdrant service container configuration.
The E2E test already has a "Wait for Qdrant" step that uses curl
from the runner environment to verify service readiness before
running tests.
Impact:
- Qdrant container will start immediately without health check delays
- Service readiness still verified by test-level wait step
- Eliminates container startup failures
Testing:
Next CI run should successfully start Qdrant container and pass
the wait/verify steps in the test workflow.
Why this change is needed:
E2E tests were failing in GitHub Actions CI with two critical issues:
1. PostgreSQL tests failed with "ModuleNotFoundError: No module named 'qdrant_client'"
2. Qdrant container health check never became healthy
How it solves it:
1. Added qdrant-client to PostgreSQL job dependencies
- test_e2e_multi_instance.py imports QdrantClient at module level
- Even with -k "postgres" filter, pytest imports the whole module first
- Both PostgreSQL and Qdrant tests now share dependencies
2. Changed Qdrant health check from curl to wget
- Qdrant Docker image may not have curl pre-installed
- wget is more commonly available in minimal container images
- New command: wget --no-verbose --tries=1 --spider
Impact:
- Fixes PostgreSQL E2E test import errors
- Enables Qdrant container to pass health checks
- Allows both test suites to run successfully in CI
Testing:
- Will verify in next CI run that both jobs complete successfully
- Health check should now return "healthy" status within retry window
Why this change is needed:
While unit tests with mocks verify code logic, they cannot catch real-world
issues like database connectivity, SQL syntax errors, vector dimension mismatches,
or actual data migration failures. E2E tests with real database services provide
confidence that the feature works in production-like environments.
What this adds:
1. E2E workflow (.github/workflows/e2e-tests.yml):
- PostgreSQL job with ankane/pgvector:latest service
- Qdrant job with qdrant/qdrant:latest service
- Runs on Python 3.10 and 3.12
- Manual trigger + automatic on PR
2. PostgreSQL E2E tests (test_e2e_postgres_migration.py):
- Fresh installation: Create new table with model suffix
- Legacy migration: Migrate 10 real records from legacy table
- Multi-model: Two models create separate tables with different dimensions
- Tests real SQL execution, pgvector operations, data integrity
3. Qdrant E2E tests (test_e2e_qdrant_migration.py):
- Fresh installation: Create new collection with model suffix
- Legacy migration: Migrate 10 real vectors from legacy collection
- Multi-model: Two models create separate collections (768d vs 1024d)
- Tests real Qdrant API calls, collection creation, vector operations
How it solves it:
- Uses GitHub Actions services to spin up real databases
- Tests connect to actual PostgreSQL with pgvector extension
- Tests connect to actual Qdrant server with HTTP API
- Verifies complete data flow: create → migrate → verify
- Validates dimension isolation and data integrity
Impact:
- Catches database-specific issues before production
- Validates migration logic with real data
- Confirms multi-model isolation works end-to-end
- Provides high confidence for merge to main
Testing:
After this commit, E2E tests can be triggered manually from GitHub Actions UI:
Actions → E2E Tests (Real Databases) → Run workflow
Expected results:
- PostgreSQL E2E: 3 tests pass (fresh install, migration, multi-model)
- Qdrant E2E: 3 tests pass (fresh install, migration, multi-model)
- Total: 6 E2E tests validating real database operations
Note:
E2E tests are separate from fast unit tests and only run on:
1. Manual trigger (workflow_dispatch)
2. Pull requests that modify storage implementation files
This keeps the main CI fast while providing thorough validation when needed.
Why this change is needed:
Before creating a PR, we need to validate that the vector storage model isolation
feature works correctly in the CI environment. The existing tests.yml only runs
on main/dev branches and only tests marked as 'offline'. We need a dedicated
workflow to test feature branches and specifically run migration tests.
What this adds:
- New workflow: feature-tests.yml
- Triggers on:
1. Manual dispatch (workflow_dispatch) - can be triggered from GitHub UI
2. Push to feature/** branches - automatic testing
3. Pull requests to main/dev - pre-merge validation
- Runs migration tests across Python 3.10, 3.11, 3.12
- Specifically tests:
- test_qdrant_migration.py (6 tests)
- test_postgres_migration.py (6 tests)
- Uploads test results as artifacts
How to use:
1. Automatic: Push to feature/vector-model-isolation triggers tests
2. Manual: Go to Actions tab → Feature Branch Tests → Run workflow
3. PR: Tests run automatically when PR is created
Impact:
- Enables pre-PR validation on GitHub infrastructure
- Catches issues before code review
- Provides test results across multiple Python versions
- No need for local test environment setup
Testing:
After pushing this commit, tests will run automatically on the feature branch.
Can also be triggered manually from GitHub Actions UI.
- Add GitHub Actions workflow for CI
- Mark integration tests requiring services
- Add offline test markers for isolated tests
- Skip integration tests by default
- Configure pytest markers and collection
• Uses exact versions from `bun.lock` without updating
• Skips devDependencies, saving time and bandwidth
• The --emptyOutDir already configured in vite.config.ts
* Fetch full git history for tags
* Extract version from latest git tag
* Update __init__.py with tag version
* Display updated version for verification
