Skip to content

docs: plan refuses a blocked residency, Unity Catalog tag values as written, and readable table names in logs (forge-cli#868) - #212

Merged
fas89 merged 1 commit into
mainfrom
docs/plan-sovereignty-uc-tags-868
Nov 13, 2026
Merged

fas89 merged 1 commit into
mainfrom
docs/plan-sovereignty-uc-tags-868

Conversation

@fas89

@fas89 fas89 commented Nov 13, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Documents forge-cli #868, released in 0.30.0.

  • fluid plan checks sovereignty by default (docs/cli/plan.md). It refuses what fluid validate refuses. Under strict that includes a binding outside allowedRegions, one in another jurisdiction, and one on AWS, GCP, Azure or Databricks that declares no region. In every mode it includes a region in deniedRegions. A refusal exits 1 with ERR_SOVEREIGNTY_VIOLATION and writes no plan. --check-sovereignty runs that check first, then the provider hook, and writes no plan on failure. --no-check-sovereignty skips the check with a warning and a WARNING log (sovereignty_check_skipped).
  • Unity Catalog tag values as written (docs/providers/databricks.md): case, spaces and punctuation kept, fluid_regulation joined with , , a value over 256 characters refused as databricks-tag-value-too-long, and the in-place update (~) of a deployment made before 0.30.0.
  • docs/advanced/error-codes.md: the 0.30.0 sovereignty_violation suggestions, and a governance label as a databricks-tag-value-too-long trigger.
  • docs/upgrading.md: all three changes, the log-redaction one included, added to the ## Changes in 0.30.0 section docs(databricks): metric views, and a schema the contract stops using is destroyed (forge-cli#865, #873) #211 created. The plan change comes first, since it can stop a pipeline on any provider. The tag change is a bullet under ### Databricks.
  • Pages the same change made wrong: docs/advanced/governance.md called plan's check opt-in, docs/concepts/sovereignty.md listed only plan --check-sovereignty, and the walkthrough's stage 6 said a failing plan still writes its file. The walkthrough now shows the 0.30.0 refusal.

Related CLI PR

Areas Updated

  • Getting Started
  • CLI Reference
  • Provider Docs
  • Walkthroughs / Examples
  • Contributing / Community Docs
  • Other: upgrading, error codes, governance, sovereignty concepts, the docs-check allowlist

Checklist

  • I previewed the change locally with npm run docs:dev or built it with npm run docs:build
  • I checked links, page titles, and navigation where relevant
  • Screenshots or command output are updated if needed

Notes

Observed on the release. Each behaviour was run on data-product-forge==0.30.0 from PyPI in a scratch venv, and compared with 0.29.0:

Contract and run 0.29.0 0.30.0
strict, binding in deniedRegions: fluid plan exit 0, plan written exit 1, no plan
the same, a file already at --out exit 1, the file unchanged
the same, --check-sovereignty exit 1, plan written exit 1, no plan
the same, --no-check-sovereignty exit 0, plan written, warning
strict, a GCP binding with no region: fluid plan exit 0, plan written exit 1, no plan
advisory or audit, binding in deniedRegions exit 1, no plan
advisory, binding only outside allowedRegions; or no sovereignty block exit 0, nothing printed

Under strict, a GCP binding outside allowedRegions is now refused by the default check before the gcp hook is asked, so plan.md says the hook's example output predates 0.30.0. The walkthrough's new output block is a real 0.30.0 run: no plan.json and no plan.html are written.

fluid generate iac on one Databricks contract gives the same 17 tag addresses on both releases, with these values:

Tag 0.29.0 0.30.0
cost_center cc-42 CC-42
fluid_jurisdiction us US
fluid_regulation gdpr_ccpa GDPR, CCPA
a 257-character label cut to 63 refused, databricks-tag-value-too-long

redact_secret_text() masks catalog.schema.table on 0.29.0 and keeps it on 0.30.0, and a JWT stays masked on both. The live Free Edition run (+0 ~17 -0, then applied, values read back, fluid verify on 27 tags) is forge-cli's own, from #868 and its CHANGELOG.

An independent review pass re-ran these claims against the v0.30.0 source and both CLIs. Its should-fix findings are folded in: the missing-region case, apply's checks linked rather than named per cloud, the hook-path sentence in upgrading.md, the 0.29.0 slug keeping _, and the live-run wording.

Allowlist. The docs checks pin 0.29.0, whose plan parser has no --no-check-sovereignty. Without docs/cli/plan.md::--no-check-sovereignty under flag_oracle_ok, the flag oracle fails on plan.md's example; with it, it passes. Against 0.30.0 the oracle passes without the entry, so the pin bump should drop it.

Checks run locally on the branch rebased onto #211 (pinned 0.29.0, forge-cli's CHANGELOG through 0.30.0): check_cli_docs.py (all checks, markers included), check_providers.py, gen_contract_reference.py --check, npm run docs:build and node scripts/check-dist-links.mjs. All clean.

Not in this PR. The 0.30.0 pin bump: the markers that still call #861, #864 and #871 unreleased, and the "Not in a release yet" section of upgrading.md. Also a gap in the release-marker sweep that lets those markers pass CI. Both are tracked separately.

…ritten, and readable table names in logs (forge-cli#868)

Document forge-cli #868, released in 0.30.0:

- plan.md: plan checks the sovereignty policy by default and refuses
  what fluid validate refuses (exit 1, ERR_SOVEREIGNTY_VIOLATION, no
  plan written; a file already at --out stays). --check-sovereignty
  runs that check first, then the provider hook, and writes no plan on
  failure. --no-check-sovereignty skips the check with a warning.
- databricks.md: tag values as the contract states them, the
  256-character refusal, and the in-place update of a deployment made
  before 0.30.0.
- error-codes.md: the 0.30.0 sovereignty_violation suggestions, and a
  governance label as a databricks-tag-value-too-long trigger.
- upgrading.md: the three changes under "Changes in 0.30.0".
- governance.md, concepts/sovereignty.md and the walkthrough's stage 6
  no longer call plan's check opt-in or say a failing plan still
  writes its file; the walkthrough shows the 0.30.0 refusal.

Each behaviour was observed on data-product-forge 0.30.0 from PyPI and
compared with 0.29.0: plan on a strict contract with its binding in
deniedRegions exits 1 and writes no plan; the emitted Unity Catalog
tags keep case and punctuation; a 257-character value is refused.

The flag oracle runs against the pinned 0.29.0 parser, which has no
--no-check-sovereignty, so plan.md's example is allowlisted until the
0.30.0 pin bump.

This branch was previously deployed

1 inactive deployment
github-pages — aa954357 Deployed Nov 13, 2026 by fas89 via deploy #309
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant