[CT-3318] [Feature] Support the group resource type within dbt list

[dbeatty10]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

In order to find the file in which a group is defined, I'd like to be able to do one or more of the following:

dbt list --resource-type group
dbt list --resource-type group --output path
dbt -q list --resource-type group --output json --output-keys name path

But currently get the following message:

$ dbt list --resource-type group

Usage: dbt list [OPTIONS]
Try 'dbt list -h' for help.

Error: Invalid value for '--resource-types' / '--resource-type': 'group' is not one of 'metric', 'semantic_model', 'source', 'analysis', 'model', 'test', 'exposure', 'snapshot', 'seed', 'default', 'all'.

A regular listing will show that I have 1 group defined though:

$ dbt list                      
12:42:12  Running with dbt=1.7.0
12:42:15  Registered adapter: snowflake=1.7.0
12:42:15  Found 2 models, 0 sources, 0 exposures, 0 metrics, 378 macros, 1 group, 0 semantic models

Describe alternatives you've considered

Currently, some options are:

• to intuitively know where the group is defined (e.g., using a known convention across my project)
• use some kind of code search for the group name (like grep)
• inspect manifest.json

None of these are particularly ergonomic or dbt-onic.

The last one is probably the easiest for those that know where to find this file and apply pretty-print formatting for human readability.

Who will this benefit?

This will benefit folks that already know how to use dbt list and want to use it for all the types of resources within their project.

Are you interested in contributing this feature?

No response

Anything else?

Declaring a group

• https://docs.getdbt.com/docs/build/groups#declaring-a-group

models/marts/finance/finance.yml

groups:
  - name: finance
    owner:
      email: finance@jaffleshop.com

Groups within the manifest

Here's a subset of my manifest.json after dbt parse:

    "groups": {
        "group.my_project.finance": {
            "name": "finance",
            "resource_type": "group",
            "package_name": "my_project",
            "path": "finance.yml",
            "original_file_path": "models/marts/finance/finance.yml",
            "unique_id": "group.my_project.finance",
            "owner": {
                "email": "finance@jaffleshop.com",
                "name": null
            }
        }
    },

[jtcohen6]

From discussion with @dbeatty10 live:

• dbt list should make it possible to list resources that aren't 1:1 with DAG nodes (groups, macros, on-run-* hooks)
• We should make the default behavior to list only DAG nodes, to avoid confusion/clutter. (Right now, we exclude only analyses.)
• You could still dbt list --resource-type group to get groups!

Challenge/complication: For any resource type that isn't actually a DAG node, it won't be included in the networkx graph. So as soon as there are selection criteria in the mix (like some_resource+), we'd need some other logic to apply.

Some other recent ideas for resolving dbt list inconsistencies:

• [CT-3096] Refactor selection + dbt list output, for better consistency across node types #8599

This doesn't feel high priority, but it would be nice to have, insofar as dbt list is a handy way to do "manifest introspection."

[dbeatty10]

Challenge/complication: For any resource type that isn't actually a DAG node, it won't be included in the networkx graph. So as soon as there are selection criteria in the mix (like some_resource+), we'd need some other logic to apply.

This feels okay to me!

i.e., if someone adds any selection criteria, it's totally reasonable that it would inherently drop out resource types like group.

I'm not sure if we'd actually need to put in any other logic to handle a mix of --resource-type group plus some kind --selection.