ch-migrate-cli 0.5.0__tar.gz → 0.5.1__tar.gz

{ch_migrate_cli-0.5.0 → ch_migrate_cli-0.5.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: ch-migrate-cli
-Version: 0.5.0
+Version: 0.5.1
 Summary: SQL-first ClickHouse schema migrations across environments: the ch-migrate command
 Project-URL: Homepage, https://github.com/DRYCodeWorks/ch-migrate
 Project-URL: Repository, https://github.com/DRYCodeWorks/ch-migrate
@@ -58,7 +58,7 @@ pip install ch-migrate-cli
 ch-migrate --version
 ```
 
-The command is `ch-migrate`, the PyPI package is `ch-migrate-cli` (PyPI treats `ch-migrate` as the same name as the existing, unrelated `chmigrate`), and migrations import from `ch_migrate`. Versions up to 0.4.1 were published as `clickhouse-alembic` with the import package `clickhouse_alembic`; that import still works with a deprecation warning until 1.0, so existing migration files keep running. Replace `clickhouse_alembic` with `ch_migrate` in them when convenient, and run `ch-migrate upgrade-env` to refresh `migrations/env.py`.
+The command is `ch-migrate`, the PyPI package is `ch-migrate-cli` (PyPI treats `ch-migrate` as the same name as the existing, unrelated `chmigrate`), and migrations import from `ch_migrate`. Versions up to 0.4.1 were published as `clickhouse-alembic` with the import package `clickhouse_alembic`; that import still works with a deprecation warning until 1.0, so existing migration files keep running. Replace `clickhouse_alembic` with `ch_migrate` in them when convenient. For `migrations/env.py`, run `ch-migrate upgrade-env` only if you never edited it; if you did (for example to add connection settings), change its `clickhouse_alembic` imports to `ch_migrate` by hand instead, because `upgrade-env` replaces the whole file.
 
 To switch an existing install, remove the old package first, because both install the `ch-migrate` command and the `clickhouse_alembic` folder: `uv tool uninstall clickhouse-alembic && uv tool install ch-migrate-cli`, or `pip uninstall clickhouse-alembic && pip install ch-migrate-cli`. In a project that lists `clickhouse-alembic` as a dependency, replace it with `ch-migrate-cli`.
 
@@ -285,7 +285,7 @@ Example: `ch-migrate down dev --revision base`
 
 ### `status`
 
-`ch-migrate status ENV` shows connection information, applied/pending counts, and head status, and names the `up` command when migrations are pending. No command-specific options. Exits 1 if it cannot reach the database.
+`ch-migrate status ENV` shows connection information, applied/pending counts, and head status, and names the `up` command when migrations are pending. No command-specific options. Status is a report: it exits 0 when the database is unreachable (with a warning) or migrations are pending, and exits 1 only when the configuration or `migrations/versions/` is missing, so CI can run it as a non-blocking check.
 
 Example: `ch-migrate status dev`
 
@@ -335,7 +335,7 @@ Example: `ch-migrate rebase dev --onto abc123 --dry-run`
 
 ### `upgrade-env`
 
-`ch-migrate upgrade-env` replaces `migrations/env.py` with the installed version and backs up the old file as `env.py.bak`. No command-specific options. Review and reapply local customizations from the backup.
+`ch-migrate upgrade-env` replaces `migrations/env.py` with the installed version and backs up the old file as `env.py.bak`. No command-specific options. It does not merge: any local customizations (connection settings, session pins, hooks) are dropped from the new file. Reapply them from the backup, or skip `upgrade-env` and edit a customized `env.py` by hand.
 
 Example: `ch-migrate upgrade-env`
 

{ch_migrate_cli-0.5.0 → ch_migrate_cli-0.5.1}/README.md

@@ -15,7 +15,7 @@ pip install ch-migrate-cli
 ch-migrate --version
 ```
 
-The command is `ch-migrate`, the PyPI package is `ch-migrate-cli` (PyPI treats `ch-migrate` as the same name as the existing, unrelated `chmigrate`), and migrations import from `ch_migrate`. Versions up to 0.4.1 were published as `clickhouse-alembic` with the import package `clickhouse_alembic`; that import still works with a deprecation warning until 1.0, so existing migration files keep running. Replace `clickhouse_alembic` with `ch_migrate` in them when convenient, and run `ch-migrate upgrade-env` to refresh `migrations/env.py`.
+The command is `ch-migrate`, the PyPI package is `ch-migrate-cli` (PyPI treats `ch-migrate` as the same name as the existing, unrelated `chmigrate`), and migrations import from `ch_migrate`. Versions up to 0.4.1 were published as `clickhouse-alembic` with the import package `clickhouse_alembic`; that import still works with a deprecation warning until 1.0, so existing migration files keep running. Replace `clickhouse_alembic` with `ch_migrate` in them when convenient. For `migrations/env.py`, run `ch-migrate upgrade-env` only if you never edited it; if you did (for example to add connection settings), change its `clickhouse_alembic` imports to `ch_migrate` by hand instead, because `upgrade-env` replaces the whole file.
 
 To switch an existing install, remove the old package first, because both install the `ch-migrate` command and the `clickhouse_alembic` folder: `uv tool uninstall clickhouse-alembic && uv tool install ch-migrate-cli`, or `pip uninstall clickhouse-alembic && pip install ch-migrate-cli`. In a project that lists `clickhouse-alembic` as a dependency, replace it with `ch-migrate-cli`.
 
@@ -242,7 +242,7 @@ Example: `ch-migrate down dev --revision base`
 
 ### `status`
 
-`ch-migrate status ENV` shows connection information, applied/pending counts, and head status, and names the `up` command when migrations are pending. No command-specific options. Exits 1 if it cannot reach the database.
+`ch-migrate status ENV` shows connection information, applied/pending counts, and head status, and names the `up` command when migrations are pending. No command-specific options. Status is a report: it exits 0 when the database is unreachable (with a warning) or migrations are pending, and exits 1 only when the configuration or `migrations/versions/` is missing, so CI can run it as a non-blocking check.
 
 Example: `ch-migrate status dev`
 
@@ -292,7 +292,7 @@ Example: `ch-migrate rebase dev --onto abc123 --dry-run`
 
 ### `upgrade-env`
 
-`ch-migrate upgrade-env` replaces `migrations/env.py` with the installed version and backs up the old file as `env.py.bak`. No command-specific options. Review and reapply local customizations from the backup.
+`ch-migrate upgrade-env` replaces `migrations/env.py` with the installed version and backs up the old file as `env.py.bak`. No command-specific options. It does not merge: any local customizations (connection settings, session pins, hooks) are dropped from the new file. Reapply them from the backup, or skip `upgrade-env` and edit a customized `env.py` by hand.
 
 Example: `ch-migrate upgrade-env`
 

{ch_migrate_cli-0.5.0 → ch_migrate_cli-0.5.1}/ch_migrate/__init__.py

@@ -5,7 +5,7 @@ Usage:
     from ch_migrate import read_sql, get_db, get_env_config, create_dictionary
 """
 
-__version__ = "0.5.0"
+__version__ = "0.5.1"
 
 
 from typing import Any

{ch_migrate_cli-0.5.0 → ch_migrate_cli-0.5.1}/ch_migrate/cli.py

@@ -250,14 +250,17 @@ def status(environment: str) -> None:
     """Show migration status.
 
     Displays environment info, applied/pending counts, and head status.
-    Exits 1 if the database cannot be reached.
+    Status is a report: it exits 0 even when the database cannot be reached or
+    migrations are pending, and exits 1 only when the config or migrations/versions/
+    is missing. CI jobs use it as a non-blocking reporter.
     """
     from ch_migrate.display import render_status
 
     state = _load_migration_state(environment)
     render_status(environment, state.env_config, state.graph, state.applied, db_error=state.db_error)
     if state.db_error:
-        ui.fail(f"Could not reach the database: {state.db_error.strip().splitlines()[0]}")
+        ui.warn(f"Could not reach the database: {state.db_error.strip().splitlines()[0]}")
+        return
     pending = len(set(state.graph.migrations) - (state.applied or set()))
     if pending:
         noun = "migration" if pending == 1 else "migrations"

ch_migrate_cli-0.5.1/tests/test_status_command.py

@@ -0,0 +1,36 @@
+"""`ch-migrate status` is a report: CI runs it as a non-blocking check.
+
+Sazabi's required "ClickHouse Migration Status" job relies on status exiting 0 when
+the database is unreachable or migrations are pending; only a broken project fails.
+"""
+
+import pytest
+from click.testing import CliRunner
+
+from ch_migrate import connection
+from ch_migrate.cli import main
+
+
+@pytest.fixture
+def project(tmp_path, monkeypatch):
+    result = CliRunner().invoke(main, ["init", str(tmp_path), "--name", "demo"])
+    assert result.exit_code == 0, result.output
+    monkeypatch.chdir(tmp_path)
+    monkeypatch.setenv("CH_DEV_MIGRATION_PASSWORD", "test-only")
+    return tmp_path
+
+
+def test_unreachable_database_is_reported_and_exits_zero(project, monkeypatch):
+    def refuse(env_config):
+        raise ConnectionError("Connection refused")
+
+    monkeypatch.setattr(connection, "get_current_heads", refuse)
+    result = CliRunner().invoke(main, ["status", "dev"])
+    assert result.exit_code == 0, result.output
+    assert "Could not reach the database: Connection refused" in result.output
+
+
+def test_unknown_environment_fails(project):
+    result = CliRunner().invoke(main, ["status", "nope"])
+    assert result.exit_code == 1
+    assert "Unknown environment: nope" in result.output