-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[#3885] Handle env_vars in partial parsing of SQL files #4101
Conversation
08b3578
to
0d3d84d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In basic local testing, this works wonderfully for .sql
files. I left one comment around handling secret-prefixed env vars.
I'm really excited to extend this to .yml
files, and eventually to work with var()
as well as env_var()
.
@@ -790,3 +798,28 @@ def remove_source_override_target(self, source_dict): | |||
self.remove_tests(orig_file, 'sources', orig_source['name']) | |||
self.merge_patch(orig_file, 'sources', orig_source) | |||
self.add_to_pp_files(orig_file) | |||
|
|||
def build_env_vars_to_source_files(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this method where we should check to see if env vars start with SECRET_ENV_PREFIX
, and (if so) not store their value / always invalidate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is using the stored env_var values, so probably that needs to happen earlier in the provider context env_var method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We had a chance to discuss this offline, and arrived at: we should always store *****
as the value for secret env vars, i.e., neither store their values nor invalidate/re-parse files if the (unknown) value changes. This should work well with the intended use case for secret-prefixed env vars (packages.yml
), or anticipated use in profiles.yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was slightly simpler to just not store env vars starting with the secret prefix, because otherwise we have to convert when we read them in the partial parser too. Does this work for you?
5e02006
to
54f2e55
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Only some minor suggestions.
|
||
|
||
|
||
class EnvVarTest(BasePPTest): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great test! Very easy to follow.
d6f8de7
to
01bb68c
Compare
* Fix tests for dbt-labs/dbt-core#3955 * Methods renamed in dbt-labs/dbt-core#4101 * Missed one
* Fix tests for dbt-labs/dbt-core#3955 * Methods renamed in dbt-labs/dbt-core#4101 * Missed one
resolves #3885
Description
This code collects the env_vars from contexts that inherit from ProviderContext (SQL files), stores the env_var values in the manifest, and in the partial parsing code schedules the files with changed env_vars for parsing.
In addition, this makes the function names that generate contexts consistent (generate_[name]_context) and changes the 'created_at' field in various nodes to a float (time.time()) instead of int for more precision, because it was needed in a test case. Also removed some unnecessary code from the schema parser that handled pre-v2 configs.
Checklist
CHANGELOG.md
and added information about my change