Skip to content
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

[CT-898] [Feature] Make entire dbt invocation command available to Jinja context #5524

Closed
1 task done
NiallRees opened this issue Jul 25, 2022 · 2 comments · Fixed by #5782
Closed
1 task done

[CT-898] [Feature] Make entire dbt invocation command available to Jinja context #5524

NiallRees opened this issue Jul 25, 2022 · 2 comments · Fixed by #5782
Labels
enhancement New feature or request help_wanted Trickier changes, with a clear starting point, good for previous/experienced contributors

Comments

@NiallRees
Copy link
Contributor

Is this your first time opening an issue?

Describe the Feature

Right now flags.WHICH can be used to return the top-level command, but it would be great to surface the entire command string of args, flags, vars etc. The use case here is the dbt_artifacts package's https://github.com/brooklyn-data/dbt_artifacts/blob/main/models/fct_dbt__invocations.sql model.

Even better would be to also make each section of the command accessible separately, such as the selector, any args, flags etc.

Describe alternatives you've considered

No response

Who will this benefit?

No response

Are you interested in contributing this feature?

No response

Anything else?

No response

@NiallRees NiallRees added enhancement New feature or request triage labels Jul 25, 2022
@github-actions github-actions bot changed the title [Feature] Make entire dbt invocation command available to Jinja context [CT-898] [Feature] Make entire dbt invocation command available to Jinja context Jul 25, 2022
@jtcohen6
Copy link
Contributor

jtcohen6 commented Aug 9, 2022

I think what we want here is just good old args_to_dict:

dbt-core/core/dbt/utils.py

Lines 630 to 636 in 94a7cfa

# This is used to serialize the args in the run_results and in the logs.
# We do this separately because there are a few fields that don't serialize,
# i.e. PosixPath, WindowsPath, and types. It also includes args from both
# cli args and flags, which is more complete than just the cli args.
# If new args are added that are false by default (particularly in the
# global options) they should be added to the 'default_false_keys' list.
def args_to_dict(args):

That's what we use in the MainReportArgs event, and it's also what we use when writing run_results.json. It also captures the values of "global" configs set via env var or user config (profiles.yml), instead of CLI flags.

I think this could quite naturally land as a property or method in the ProviderContext:

    @contextproperty
    def invocation_args_dict(self):
        from dbt.utils import args_to_dict  # not here, of course
        return args_to_dict(self.config.args)
select {{ invocation_args_dict }}

Note that the exact structure of the args dict is definitely liable to change, as we rework our CLI to use click instead of argparse: #5526.

@jtcohen6 jtcohen6 added help_wanted Trickier changes, with a clear starting point, good for previous/experienced contributors and removed triage labels Aug 9, 2022
@jared-rimmer
Copy link
Contributor

@jtcohen6 I've had a go at implementing this and I'm at the stage of trying to add the required tests.

Are you able to provide some direction on how tests for the ProviderContext should be implemented?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help_wanted Trickier changes, with a clear starting point, good for previous/experienced contributors
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants