Resolves #11155

Problem

Folks would like to be able to execute exports based on tags. We can't easily support individual exports in the dbt dag right now because the exports aren't proper nodes in the dbt graph, but we can provide similar functionality by allowing them to tag the saved queries that declare those exports.

This provides several types of related functionality -

• Add tags directly to the saved query in the way described in our docs for non-config objects. These can be arranged in several different forms -
  • tags: ["my_tag_1", "my_tag_2"]
  • tags: "my_tag"

  • tags:
       - "my_tag_1"
       - "my_tag_2"
    

• Add tags may also be set and inherited from config objects

Solution

To do this, updates were made to the schemas and pydantic class for saved queries in dsi in a preceding PR. In this PR, we update how the saved queries are parsed in dbt-core (for the manifest, not the semantic-manifest). We add a little special logic to handle the case where the tags argument is just a single string and to sort and de-duplicate tags because that's just nicer.

Manual Testing

To test this locally, I ran make dev and then used the local version of dbt-core to parse a test project we have.

I added this to the dbt_project.yml:

saved-queries:
  +cache:
    enabled: true
  +tags: 
    - tag_config_1
  enabled: false

(only the tags lines were new)

And I added this line to a yml file's saved query :
tags: ['tag_b', 'tag_d', 'tag_a']

I ran ~/git/dbt-core/venv/bin/dbt parse (i had some weirdness when i didn't point at my venv), and checked the manifest file and semantic manifest. they both had sections like this for the saved query:
"tags": ["tag_a", "tag_b", "tag_config_1", "tag_d"]}]}

I tried it again with lists of tags in my saved queries structured like

• tags: 
      - "tag_A"
      - "tag_2"
  

  resulting in "tags": ["tag_2", "tag_A", "tag_config_1"]}]}

• and

    tags: "tag_A"
  

  resulting in "tags": ["tag_A", "tag_config_1"]}]}

Running with these tags selected
The difference in dbt_core is actually minimal.

If I run this with a selector on tags that doesn't exist, I see:

─ ~/git/dbt-core/venv/bin/dbt build --select tag:tag_45
╰─ ~/git/dbt-core/venv/bin/dbt build --select tag:tag_45
16:35:49 Running with dbt=1.10.0-a1
16:35:49 Registered adapter: snowflake=1.8.4
16:35:50 Found 10 models, 6 seeds, 18 data tests, 15 sources, 18 metrics, 683 macros, 1 group, 5 semantic models, 1 saved query
16:35:50 The selection criterion 'tag:tag_45' does not match any enabled nodes
16:35:50 The selection criterion 'tag:tag_45' does not match any enabled nodes
16:35:50 The selection criterion 'tag:tag_45' does not match any enabled nodes
16:35:50 Nothing to do. Try checking your model configs and model specification args

Whereas with a real tag, we build as expected:

~/git/dbt-core/venv/bin/dbt build --select tag:tag_a
16:35:55 Running with dbt=1.10.0-a1
16:35:55 Registered adapter: snowflake=1.8.4
16:35:55 Found 10 models, 6 seeds, 18 data tests, 15 sources, 18 metrics, 683 macros, 1 group, 5 semantic models, 1 saved query
16:35:55
16:35:55 Concurrency: 8 threads (target='dev')
16:35:55
16:35:57 1 of 1 NO-OP saved query with_list_tags_v2 ..................................... [NO-OP in 0.00s]
16:35:57
16:35:57 Finished running 1 saved query in 0 hours 0 minutes and 1.42 seconds (1.42s).
16:35:57
16:35:57 Completed successfully
16:35:57
16:35:57 Done. PASS=0 WARN=0 ERROR=0 SKIP=0 NO-OP=1 TOTAL=1

Checklist

• I have read the contributing guide and understand what's expected of me.
• I have run this code in development, and it appears to resolve the stated issue.
• This PR includes tests, or tests are not required or relevant for this PR.
• This PR has no interface changes (e.g., macros, CLI, logs, JSON artifacts, config files, adapter interface, etc.) or this PR has already received feedback and approval from Product or DX.
• This PR includes type annotations for new and modified functions.