cassis-cli 3.1.0__tar.gz → 3.1.1__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: cassis-cli
3
- Version: 3.1.0
3
+ Version: 3.1.1
4
4
  Summary: Validate, test and evaluate your Cassis context from your terminal, then publish it
5
5
  License: Apache-2.0
6
6
  License-File: LICENSE
@@ -27,7 +27,7 @@ Validate, test and evaluate your context from your terminal, then publish it. Th
27
27
  - `cassis context check` validates the context files in your repository with the exact same checks as the Cassis GitHub PR check (YAML parsing, round-trip, import validation), so you can gate merges in any CI system, not just GitHub. It then prints advisory **context quality warnings** for a tree that parsed: tables not assigned to any domain, joins/metrics pointing at unknown tables or columns, missing table/column descriptions (the same findings `context test` reports, without the agent run). In a checkout bound to a project (`project.yml`, `--project`, or `CASSIS_PROJECT_ID`), it also cross-checks the tree against the project's source schema: references to tables or columns the warehouse doesn't have print as **warnings** too, advisory only (the object may simply not be built or synced yet). Warnings never fail the check.
28
28
  - `cassis schema pull` downloads the data source's full source schema (as Cassis last introspected it) into `<base-path>/.schema.json`, a **gitignored** local snapshot (the command maintains the ignore entry) with a `pulled_at` stamp. The warehouse stays authoritative; the snapshot is a cache for offline/bulk work, e.g. a coding agent grepping table and column names during a modeling pass instead of paging through the MCP `get_source_schema` tool. Re-run to refresh.
29
29
  - `cassis context fmt` rewrites the context files in canonical form (think `black`/`gofmt` for your context), so hand or agent edits pass the round-trip check.
30
- - `cassis context upload` uploads the context files to a Cassis project (full replace) and, by default, publishes them immediately as a new version, so a merge to your main branch can go live in one CI step. It runs from a git checkout whose context files are committed, and the published version records that commit, so `cassis status` can tell whether a checkout matches what is live.
30
+ - `cassis context upload` uploads the context files to a Cassis project (full replace) and, by default, publishes them immediately as a new version, so a merge to your main branch can go live in one CI step. It runs from a git checkout whose context files are committed, and the published version records that commit, even when the upload changes nothing, so `cassis status` can tell whether a checkout matches what is live.
31
31
  - `cassis context pull` downloads the project's unpublished context into your repository checkout (full sync: stale local context files are pruned), so you can start editing from the current state, or bootstrap a repo that isn't git-synced (e.g. Bitbucket). Pruning only deletes files that are tracked and unmodified in git (i.e. restorable with `git checkout`); untracked or locally modified files are kept and listed, and every deleted path is printed.
32
32
  - `cassis context pull` and `cassis context fmt` also write `<base-path>/AGENTS.md`, the Cassis context design guide, into the checkout (default `cassis/AGENTS.md`). It is a managed file (generated banner; the CLI overwrites local edits) so a repo-aware coding agent loads current Cassis modeling doctrine by convention. It sits inside the context directory but is not part of the context tree (which is the YAML files plus the domain Markdown files `domains/**/README.md`), so it is never uploaded, validated, or pruned. Commit it alongside your context changes. The guide text ships inside the CLI package, so its version tracks the **installed cassis-cli version**: upgrade the CLI (`pip install -U cassis-cli`) and re-run `fmt` to pick up doctrine updates; an unpinned `pip install cassis-cli` in CI gets them automatically. The banner stamps a doctrine version, and the CLI never *downgrades* the file: if the checkout's `AGENTS.md` was written by a newer doctrine (a newer CLI, or Cassis itself on a publish), `fmt`/`pull` leave it in place, print an upgrade notice, and `fmt --check` still passes.
33
33
  - The CLI identifies itself to the API (`User-Agent: cassis-cli/<version>`), and successful API responses advertise the newest published version. When you are behind, commands print a one-line upgrade notice on stderr (purely informational; output and exit codes are unchanged).
@@ -5,7 +5,7 @@ Validate, test and evaluate your context from your terminal, then publish it. Th
5
5
  - `cassis context check` validates the context files in your repository with the exact same checks as the Cassis GitHub PR check (YAML parsing, round-trip, import validation), so you can gate merges in any CI system, not just GitHub. It then prints advisory **context quality warnings** for a tree that parsed: tables not assigned to any domain, joins/metrics pointing at unknown tables or columns, missing table/column descriptions (the same findings `context test` reports, without the agent run). In a checkout bound to a project (`project.yml`, `--project`, or `CASSIS_PROJECT_ID`), it also cross-checks the tree against the project's source schema: references to tables or columns the warehouse doesn't have print as **warnings** too, advisory only (the object may simply not be built or synced yet). Warnings never fail the check.
6
6
  - `cassis schema pull` downloads the data source's full source schema (as Cassis last introspected it) into `<base-path>/.schema.json`, a **gitignored** local snapshot (the command maintains the ignore entry) with a `pulled_at` stamp. The warehouse stays authoritative; the snapshot is a cache for offline/bulk work, e.g. a coding agent grepping table and column names during a modeling pass instead of paging through the MCP `get_source_schema` tool. Re-run to refresh.
7
7
  - `cassis context fmt` rewrites the context files in canonical form (think `black`/`gofmt` for your context), so hand or agent edits pass the round-trip check.
8
- - `cassis context upload` uploads the context files to a Cassis project (full replace) and, by default, publishes them immediately as a new version, so a merge to your main branch can go live in one CI step. It runs from a git checkout whose context files are committed, and the published version records that commit, so `cassis status` can tell whether a checkout matches what is live.
8
+ - `cassis context upload` uploads the context files to a Cassis project (full replace) and, by default, publishes them immediately as a new version, so a merge to your main branch can go live in one CI step. It runs from a git checkout whose context files are committed, and the published version records that commit, even when the upload changes nothing, so `cassis status` can tell whether a checkout matches what is live.
9
9
  - `cassis context pull` downloads the project's unpublished context into your repository checkout (full sync: stale local context files are pruned), so you can start editing from the current state, or bootstrap a repo that isn't git-synced (e.g. Bitbucket). Pruning only deletes files that are tracked and unmodified in git (i.e. restorable with `git checkout`); untracked or locally modified files are kept and listed, and every deleted path is printed.
10
10
  - `cassis context pull` and `cassis context fmt` also write `<base-path>/AGENTS.md`, the Cassis context design guide, into the checkout (default `cassis/AGENTS.md`). It is a managed file (generated banner; the CLI overwrites local edits) so a repo-aware coding agent loads current Cassis modeling doctrine by convention. It sits inside the context directory but is not part of the context tree (which is the YAML files plus the domain Markdown files `domains/**/README.md`), so it is never uploaded, validated, or pruned. Commit it alongside your context changes. The guide text ships inside the CLI package, so its version tracks the **installed cassis-cli version**: upgrade the CLI (`pip install -U cassis-cli`) and re-run `fmt` to pick up doctrine updates; an unpinned `pip install cassis-cli` in CI gets them automatically. The banner stamps a doctrine version, and the CLI never *downgrades* the file: if the checkout's `AGENTS.md` was written by a newer doctrine (a newer CLI, or Cassis itself on a publish), `fmt`/`pull` leave it in place, print an upgrade notice, and `fmt --check` still passes.
11
11
  - The CLI identifies itself to the API (`User-Agent: cassis-cli/<version>`), and successful API responses advertise the newest published version. When you are behind, commands print a one-line upgrade notice on stderr (purely informational; output and exit codes are unchanged).
@@ -375,7 +375,13 @@ def upload(
375
375
  f"{result['join_count']} joins, {result['metric_count']} metrics"
376
376
  )
377
377
  version = result.get("published_version")
378
- if version is not None:
378
+ if version is not None and result.get("unchanged"):
379
+ typer.secho(
380
+ f"✓ Context uploaded ({counts}). No change: v{version} stays published, "
381
+ f"and now records commit {head[:9]}.",
382
+ fg=typer.colors.GREEN,
383
+ )
384
+ elif version is not None:
379
385
  typer.secho(f"✓ Context uploaded and published as v{version} ({counts}).", fg=typer.colors.GREEN)
380
386
  else:
381
387
  typer.secho(
@@ -71,12 +71,25 @@ def _local_comparison(path: Path, head: Optional[str], published_sha: Optional[s
71
71
  return f"diverged from the published commit {published_sha[:9]}", False
72
72
 
73
73
 
74
+ def _published_commit(published: "dict[str, Any]") -> Optional[str]:
75
+ """The newest commit known to hold the published content.
76
+
77
+ An upload that changes nothing publishes no version but moves
78
+ `latest_git_commit_sha` forward. Servers older than that field only send
79
+ `git_commit_sha`, the commit the version was published from.
80
+ """
81
+ return published.get("latest_git_commit_sha") or published.get("git_commit_sha")
82
+
83
+
74
84
  def _render(status_record: "dict[str, Any]", comparison_text: str) -> None:
75
85
  published = status_record.get("published_version")
76
86
  if published:
77
87
  label = f" {published['label']!r}" if published.get("label") else ""
78
88
  sha = published.get("git_commit_sha")
89
+ latest = _published_commit(published)
79
90
  sha_text = f", commit {sha[:9]}" if sha else ""
91
+ if latest and latest != sha:
92
+ sha_text += f", unchanged at {latest[:9]}"
80
93
  typer.echo(f"Published: v{published['version']}{label} ({published.get('published_at')}{sha_text})")
81
94
  else:
82
95
  typer.echo("Published: nothing yet")
@@ -164,7 +177,7 @@ def status(
164
177
  """The status record plus the local comparison it implies: (record, comparison_text, in_sync)."""
165
178
  record = get_project_status(api_url=api_url, api_key=api_key, project_id=project_id)
166
179
  published = record.get("published_version") or {}
167
- comparison_text, in_sync = _local_comparison(path, head, published.get("git_commit_sha"))
180
+ comparison_text, in_sync = _local_comparison(path, head, _published_commit(published))
168
181
  return record, comparison_text, in_sync
169
182
 
170
183
  def report(snapshot: "Tuple[dict[str, Any], str, bool]") -> None:
@@ -175,7 +188,7 @@ def status(
175
188
  _render(record, comparison_text)
176
189
  else:
177
190
  published = record.get("published_version") or {}
178
- published_sha = published.get("git_commit_sha")
191
+ published_sha = _published_commit(published)
179
192
  version_text = f"v{published['version']}" if published else "nothing published"
180
193
  line = f"{version_text} (commit {published_sha[:9] if published_sha else 'none'}); local: {comparison_text}"
181
194
  if line != last_line["text"]:
@@ -1,6 +1,6 @@
1
1
  [project]
2
2
  name = "cassis-cli"
3
- version = "3.1.0"
3
+ version = "3.1.1"
4
4
  description = "Validate, test and evaluate your Cassis context from your terminal, then publish it"
5
5
  readme = "README.md"
6
6
  license = { text = "Apache-2.0" }
File without changes
File without changes
File without changes