Docs · 02

Configuration

bricksentry.yml tells bricksentry where to run, which tables to watch and how to find candidates.

bricksentry.yml

backend: {type: databricks, warehouse_id: abc123}
sandbox_schema: main.bricksentry_sandbox
candidate_pattern: "{catalog}.{schema}_pr_{pr}.{table}"
sample_pct: 10
lineage: {type: databricks, depth: 3, lookback_days: 90}
tables:
  main.sales.orders:
    keys: [order_id]
    segment_by: [region]
    paths: ["src/pipelines/orders/**", "resources/orders_job.yml"]
policy: policy.yml

Keys

Key	What it does
`backend`	Where the SQL runs. type is databricks (or duckdb for local demos); warehouse_id is the SQL warehouse. Falls back to DATABRICKS_WAREHOUSE_ID.
`sandbox_schema`	Schema where preview_write creates disposable shallow clones. Needs CREATE TABLE.
`candidate_pattern`	How to find the table your change built. {catalog}, {schema}, {table} and {pr} are substituted, so main.sales.orders for PR 42 becomes main.sales_pr_42.orders.
`sample_pct`	Hash-sampling percentage for large tables. Sampling is deterministic on the key, so reruns compare the same rows.
`lineage`	Lineage provider and limits. depth is how many hops downstream to walk; lookback_days is how far back in system.access.table_lineage to look.
`tables.<name>.keys`	Columns that identify a row. Required: the diff matches production and candidate on these.
`tables.<name>.segment_by`	Columns used to find where a change is concentrated, e.g. 100% of affected rows are region = APAC.
`tables.<name>.paths`	File globs. When a pull request touches a matching file, this table is assessed.
`policy`	Path to the policy file that decides verdicts.