[CT-648] [Feature] Distinguish what dbt command has been executed in Jinja context

[SOVALINUX]

Is this your first time opening an issue?

• I have read the expectations for open source contributors

Describe the Feature

Hi colleagues,
In multiple advanced cases like dbt hooks, operations and unit testing we would like to execute queries against the database and also run some state changing operations (e.g. agate table print to file)
Currently dbt doesn't gives the opportunity to avoid such misbehavior

Suggested idea is to add executed_command to the Jinja context storing compile | run | test | docs etc from dbt command palette

So all macroses for hooks and operations can use it and flexibly configure when to run and what
Same for unit testing use-cases:

1. I can skip unit tests on dbt compile and dbt docs
2. I can now mock current_timestamp function in dbt_utils to write advanced tests without changing the logic

Describe alternatives you've considered

I was trying to do workarounds using tags and relying on presence of attributes like run_result, schemas, graph nodes in the Jinja context
Some of them are working, but all of them doesn't smell good

Who will this benefit?

Looks like multiple developers are facing the same issue
So, users of hooks, operations and unit-testing will benefit

Are you interested in contributing this feature?

Yes, PR will come soon

Anything else?

Easily found several related cases
#4785
#4445

[jeremyyeo]

Hey @SOVALINUX, have you taken a look at flags.WHICH (https://docs.getdbt.com/reference/dbt-jinja-functions/flags) by any chance?

Kind of wondering if (flags.WHICH + execute) simply gives you what you need to do what you had wanted to with this proposed executed_command Jinja context?

[jtcohen6]

Agreed! I'm pretty sure that flags.WHICH is what you're after here @SOVALINUX. Newly available since v1.0:

dbt-core/core/dbt/flags.py

Line 129 in 0d8e061

WHICH = getattr(args, "which", WHICH)

The reason we encourage you to wrap flags.WHICH in if execute, like all attributes of flags, is because it shouldn't be used for any information that dbt needs at parse time (ref/source/config). Otherwise, dbt would need to fully re-parse your project for all subsequent invocations, since the command, args, and flags you're running are obviously liable to change.

I'm going to close the issue, since I believe it's already implemented :)

[SOVALINUX]

@jeremyyeo @jtcohen6 Thank you for response! It's indeed the same thing
But I wonder should we give a better name to this flag? Should we rename the feature or create a new one?
I've read the documentation on flags and jinja context several times, even dumped all flags to the logs, but haven't noticed this one
DBT itself calls it commands (https://docs.getdbt.com/reference/dbt-commands)
Another community members decided to struggle rather than contributing into it since they also haven't found it with such a name

[jtcohen6]

@SOVALINUX Super fair! I'd be open to a new issue for renaming this field, to something more like command.

It's called which throughout dbt-core's codebase, and in its metadata, so that was the most expedient when initially adding it. This nomenclature does indeed feel closer to the metal of our argparse implementation, than what we probably want long-term. We'd just need to provide backwards compatibility for the current places where which is present.