Summary
Inspect side of the publish / unpublish loop. dbts shared shows which roles can read what in the sandbox, so you can confirm a publish stuck or notice a stale --to-role grant you forgot to revoke.
Why
After dbts publish, there's no way to verify the grants applied without writing your own SHOW GRANTS SQL. Also useful for cleanup: "did I actually unpublish before dropping?".
Sketch
- Run
SHOW GRANTS ON DATABASE <sandbox> plus future-grants queries.
- Render: role → privilege → object-type table.
- Highlight
PUBLIC rows so you can see at a glance whether the sandbox is currently QA-visible.
- Optional
--json flag for scripting.
Where it'd live
- New
src/dbts/shared.py, or a function inside publish.py since the data is the inverse of what publish writes.
- Reuse
snowflake.connect / run_sql and the sandbox-validation helpers.
Effort
Small.
Tier
Tier 1 — recommended (closes the publish loop).
Related
- Pairs with
dbts publish / dbts unpublish (already shipped).
Summary
Inspect side of the
publish/unpublishloop.dbts sharedshows which roles can read what in the sandbox, so you can confirm apublishstuck or notice a stale--to-rolegrant you forgot to revoke.Why
After
dbts publish, there's no way to verify the grants applied without writing your ownSHOW GRANTSSQL. Also useful for cleanup: "did I actually unpublish before dropping?".Sketch
SHOW GRANTS ON DATABASE <sandbox>plus future-grants queries.PUBLICrows so you can see at a glance whether the sandbox is currently QA-visible.--jsonflag for scripting.Where it'd live
src/dbts/shared.py, or a function insidepublish.pysince the data is the inverse of whatpublishwrites.snowflake.connect/run_sqland the sandbox-validation helpers.Effort
Small.
Tier
Tier 1 — recommended (closes the publish loop).
Related
dbts publish/dbts unpublish(already shipped).