Jinja context variable for selected resources

Describe the feature

A Jinja context variable that includes the list of resources (by unique_id) selected in the current invocation:

{% if 'model.package_name.my_model' in selected_resources %}
  ...
{% endif %}

This would have similar caveats to graph and execute, because it wouldn’t be populated at parse time, only at compile/execute/runtime.

Bonus points if it includes DAG information, i.e. the order in which resources will be queued for execution.

Use cases:

• An on-run-start hook that wants to know all resources about to execute. This is available in the on-run-end context, in the form of the Results object.
• Use standard node selection syntax as the input to a macro. E.g. run audit_helper.compare_relations() for each resource selected/built by a CI job, to ensure no regressions, by looping over selected_resources in a run-operation (https://github.com/fishtown-analytics/dbt/issues/2740)
  • Could we do a half-decent version of this with Results today in an on-run-end hook?
  • Is this better as post-hook on each model?

Describe alternatives you’ve considered

• Adding a property to manifest nodes: selected: true|false. Then users would access the same graph context variable and use that property. I understand that some users already do something similar, e.g. inspect the tags on each node, to emulate selection criteria. We could also consider selection_criteria, detailing why a given node has been selected. This could be included in the list output and a helpful tool for visualizing selection groupings.

• Make the selection criteria directly available, via flags.args.models and flags.args.exclude: https://github.com/fishtown-analytics/dbt/issues/2253#issuecomment-606637983

Additional context

Further down the road:

• The run-operation task should accept --select and --selector
• Custom tasks (https://github.com/fishtown-analytics/dbt/issues/2381) that can run nodes in parallel using threads, rather than in sequence

Who will this benefit?

This comes up in a surprising number of more-complex use cases.

[b-per]

No worries, I’ll create the issue and draft a PR

[jtcohen6]

Very cool! @b-per Any chance I could ask you to open an issue in https://github.com/dbt-labs/docs.getdbt.com to get this documented for v1.1?