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

[NiallRees]

Is this your first time opening an issue?

• [X] I have read the expectations for open source contributors

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

[jtcohen6]

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

https://github.com/dbt-labs/dbt-core/blob/94a7cfa58df3df5d3b07b619c0510fead9195700/core/dbt/utils.py#L630-L636

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: https://github.com/dbt-labs/dbt-core/issues/5526.

[jared-rimmer]

@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?