You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am running an SQL Validation in a Github action on my branch. The branch has only one view changed and I would expect the incremental run to find the explores where this view is used and only check these elements.
TLDR: Is it an expected behaviour that incremental SQL validations are always getting all dimensions from all explores and test all queries regardless if there was any change in a view or an explore?
Here are some details:
I call spectacles with this command: spectacles sql --project delivery --branch ${GITHUB_HEAD_REF:-${GITHUB_REF#refs/heads/}} --incremental --remote-reset --concurrency 20 --ignore-hidden -v
The ${GITHUB_HEAD_REF:-${GITHUB_REF#refs/heads/}} is correctly set to spectacles-sql-checks what is my branch name.
I would expect that it would only get the elements for one Explore and only check those. Instead, it tries to get everything and runs for over 6 hours.
From the logs, I can see that it gets all the explores:
...
Setting Git state for project 'delivery' @ spectacles-sql-checks:
...
Getting all models and explores from https://MY_COMPANY.cloud.looker.com
...
Getting all dimensions from explore ... (<- FOR EVERY EXPLORE)
Creating async query for ... (<- FOR EVERY EXPLORE)
Query for ... created as ... (<- FOR EVERY EXPLORE)
Retrieving the SQL for query ... (<- FOR EVERY QUERY CREATED FOR ALL THE EXPLORES)
Retrieved compiled SQL for query ... (<- FOR EVERY QUERY CREATED FOR ALL THE EXPLORES)
...
Setting Git state for project 'delivery' @ production:
... (SAME AS FOR THE spectacles-sql-checks TARGET)
...
================= Testing 155/310 explores [concurrency = 20] ==================
...
... (THIS RUNS OVER A THOUSAND QUERIES AND AFTER 6 HOURS I KILLED THE PROCESS)
Running this check locally I get the same behaviour.
I would expect that Specatcles runs the same way as if I would have manually added a flag to filter for the Explore --explores. For example like this: spectacles sql --project delivery --explores delivery/my_changed_explore_in_this_project
This command correctly tests only the elements in one Explore.
Just for the reference. Here is one screenshot from Github to show you the changes in my PR. On this PR Spectacles still checks all Explores even if it is in the incremental mode.
The text was updated successfully, but these errors were encountered:
Hey,
I am running an SQL Validation in a Github action on my branch. The branch has only one view changed and I would expect the
incremental
run to find the explores where this view is used and only check these elements.TLDR: Is it an expected behaviour that incremental SQL validations are always getting all dimensions from all explores and test all queries regardless if there was any change in a view or an explore?
Here are some details:
I call spectacles with this command:
spectacles sql --project delivery --branch ${GITHUB_HEAD_REF:-${GITHUB_REF#refs/heads/}} --incremental --remote-reset --concurrency 20 --ignore-hidden -v
The
${GITHUB_HEAD_REF:-${GITHUB_REF#refs/heads/}}
is correctly set tospectacles-sql-checks
what is my branch name.I would expect that it would only get the elements for one Explore and only check those. Instead, it tries to get everything and runs for over 6 hours.
From the logs, I can see that it gets all the explores:
Running this check locally I get the same behaviour.
I would expect that Specatcles runs the same way as if I would have manually added a flag to filter for the Explore
--explores
. For example like this:spectacles sql --project delivery --explores delivery/my_changed_explore_in_this_project
This command correctly tests only the elements in one Explore.
Just for the reference. Here is one screenshot from Github to show you the changes in my PR. On this PR Spectacles still checks all Explores even if it is in the incremental mode.
The text was updated successfully, but these errors were encountered: