CoreRasurae
0c5b140d29
CI / push-validation (pull_request) Successful in 18s
CI / lint (pull_request) Successful in 26s
CI / helm (pull_request) Successful in 38s
CI / build (pull_request) Successful in 48s
CI / quality (pull_request) Successful in 54s
CI / security (pull_request) Successful in 55s
CI / typecheck (pull_request) Successful in 57s
CI / e2e_tests (pull_request) Successful in 4m48s
CI / unit_tests (pull_request) Successful in 8m5s
CI / integration_tests (pull_request) Successful in 9m23s
CI / docker (pull_request) Successful in 1m23s
CI / coverage (pull_request) Successful in 12m29s
CI / benchmark-regression (push) Failing after 0s
CI / benchmark-publish (push) Failing after 0s
CI / status-check (pull_request) Successful in 1s
CI / push-validation (push) Successful in 12s
CI / helm (push) Successful in 29s
CI / build (push) Successful in 3m23s
CI / lint (push) Successful in 3m38s
CI / quality (push) Successful in 3m40s
CI / security (push) Successful in 4m3s
CI / typecheck (push) Successful in 4m5s
CI / e2e_tests (push) Successful in 6m42s
CI / unit_tests (push) Successful in 10m7s
CI / integration_tests (push) Successful in 10m13s
CI / docker (push) Successful in 1m46s
CI / coverage (push) Successful in 10m58s
CI / status-check (push) Successful in 2s
Move alembic configuration and migration files from repository root into the Python package structure to ensure they are included in the wheel distribution. This fix resolves the FileNotFoundError when running `agents init` in Docker containers or any environment using the built wheel distribution. Changes: - Move alembic/ directory from repo root to src/cleveragents/infrastructure/database/migrations/ - Move alembic.ini to the same new location and update script_location setting - Update MigrationRunner._find_alembic_ini() to search from the new canonical location within the package - Update create_template_db.py to point to the new alembic.ini location - Update documentation references to reflect new migration file locations - Create __init__.py for migrations package - The env.py file is imported when running tests that verify all modules can be imported without errors. However, context.config is only available when alembic is actually running migrations, not during normal module imports. This caused an AttributeError when the test tried to import the migrations.env module. - Fix by using getattr() with a default value to safely access context.config, and guard all code that uses config with None checks. This allows the module to be safely imported while still functioning correctly during migrations. Testing: - Verified MigrationRunner can locate alembic.ini in new location - Tested agents init succeeds in creating project with database - Template database creation works correctly - All migration tests should pass without changes Alembic files now follow standard Python packaging conventions, making them automatically included in wheel distributions without special configuration. ISSUES CLOSED: #4180
66 lines
2.8 KiB
Gherkin
66 lines
2.8 KiB
Gherkin
Feature: Database migration lifecycle
|
|
As a CleverAgents administrator
|
|
I want to manage database schema via Alembic migrations
|
|
So that I can safely evolve the schema with rollback capability
|
|
|
|
Background:
|
|
Given a fresh in-memory database for migration lifecycle testing
|
|
|
|
Scenario: Apply all migrations forward on a fresh database
|
|
When I run all migrations forward to head
|
|
Then the database should have all expected tables
|
|
And the current revision should be the head revision
|
|
|
|
Scenario: Roll back all migrations to base
|
|
Given all migrations have been applied
|
|
When I downgrade all migrations to base
|
|
Then the current revision should be None
|
|
And the database should have no application tables
|
|
|
|
Scenario: Round-trip forward then rollback to initial
|
|
Given all migrations have been applied
|
|
When I downgrade to the initial migration "001_initial_schema"
|
|
Then the current revision should be "001_initial_schema"
|
|
When I upgrade back to head
|
|
Then the current revision should be the head revision
|
|
|
|
Scenario: CLI db upgrade command applies migrations
|
|
When I invoke the db upgrade CLI command
|
|
Then the CLI should report a successful upgrade
|
|
And the database should have all expected tables
|
|
|
|
Scenario: CLI db current command shows revision
|
|
Given all migrations have been applied
|
|
When I invoke the db current CLI command
|
|
Then the CLI should display the current revision
|
|
|
|
Scenario: CLI db downgrade command rolls back
|
|
Given all migrations have been applied
|
|
When I invoke the db downgrade CLI command with revision "m6_004_container_metadata_column"
|
|
Then the CLI should report a successful downgrade
|
|
|
|
Scenario: Stamp logic detects pre-Alembic database
|
|
Given a database with legacy tables but no alembic_version
|
|
When I run init_or_upgrade on the legacy database
|
|
Then the database should be stamped with alembic_version
|
|
And the database revision should be at head
|
|
|
|
Scenario: init_database creates a valid schema
|
|
When I call init_database with an in-memory URL
|
|
Then the resulting engine should have a valid schema
|
|
|
|
@issue_4180 @alembic_packaging
|
|
Scenario: MigrationRunner locates alembic.ini from packaged location
|
|
Given the MigrationRunner class is available
|
|
When I call _find_alembic_ini() to locate the configuration file
|
|
Then it should find alembic.ini at the package location
|
|
And the alembic.ini should be readable and valid
|
|
|
|
@issue_4180 @alembic_packaging
|
|
Scenario: Database initialization succeeds with packaged alembic files
|
|
Given a fresh in-memory database for migration lifecycle testing
|
|
When I run all migrations forward to head
|
|
Then the database should have all expected tables
|
|
And the database should be stamped with alembic_version
|
|
And the database revision should be at head
|