https://linen.dev logo
Join Slack
Powered by
When running a CI job in dbt Cloud, elementary ano...
# community-support
s
When running a CI job in dbt Cloud, elementary anomaly tests started throw this error a couple days ago:
Copy code
Runtime Error in test <name of elementary volume anomalies test> (models/path/to/schema.yml)
  PERMISSION_DENIED: User does not have CREATE TABLE on Schema 'production.dbt_observability'
This throws an error and is unexpected because the CI job is not configured to write to the production catalog (it instead writes to a 
ci
catalog) and does not have permissions to do so. No other models or tests encounter an error like this or attempt to write to production. Strangely this was working without issue before several days ago. A quick fix was adding a 
dbt run -s elementary
invocation to our CI jobs, but this adds 2+ minutes of run time which is not ideal. Packages:
Copy code
dbt=1.6.9
upstream_prod 0.2.1
dbt_expectations 0.10.0
elementary 0.13.0
dbt_date 0.10.0 
databricks=1.6.7
m
Hey @Samuel Garfield, Checkout my answer here: https://elementary-community.slack.com/archives/C02CTC89LAX/p1702220625648309?thread_ts=1702031013.575389&amp;cid=C02CTC89LAX I think the question is if you need the elementary anomaly detection tests to run in CI or not. If not - better disable the package (including the tests) for CI.
s
@Maayan Salom we actually do need elementary tests to run in CI; we want to be able to validate that they run without error and generate the expected results before another team member gives an approving review and the creator merges
pardon delay in my own reply here
either way @Maayan Salom I don't think the answer you linked above is relevant unless I'm missing something. The issue I'm having is that: • When running a dbt cloud CI job (via Github), it's configured to write everything to the CI Databricks catalog • Elementary anomaly tests are attempting to write to the production Databricks catalog • No other dbt model runs or tests in our CI job attempt to write data to the production schema; something is happening where just Elementary anomaly tests are writing to the wrong catalog
the question isn't whether we want to enable elementary in CI; it's why, when it's enabled, anomaly tests fail because they try to write to the production catalog unless we invoke 
dbt run -s elementary
with every CI job run
o
Hi @Samuel Garfield, trying to understand your use case - how did you configure the CI job exactly? how does it differ from the production job (different profile? env variables? etc)?
s
@Ofek Weiss both jobs are dbt Cloud; they run in different environments
how did you configure the CI job exactly
dbt Cloud Env: Run in a deployment environment named 
Github
Catalog
is set to 
ci
Schema is set to 
git_pr
Deployment type is set to 
General
(and not 
Production
) Job: 
Triggered by pull request
turned on Set up using the official guide here via the official Github integration 
Defer to production
turned on Use custom environment variables so all runs are executed on a separate CI databricks SQL warehouse 
Target name
set to 
ci
how does it differ from the production job
Production jobs which behave as expected are run in our production dbt Cloud Env: Deployment type is set to 
Production
(and not 
General
) 
Catalog
is set to 
production
Schema is set to 
dbt
o
Hi @Samuel Garfield, i suspect the culprit here is the 
defer to production
, i'm not sure exactly why, but it causes elementary to be confused as to which relation it should be uploading its artifacts. Does running 
dbt run -s elementary
resolve this completely? this might help me figure out the cause
32 Views
Open in Slack
PreviousNext
Powered by