Skip to content

Conversation

smeyerre
Copy link

Resolves #8986

Problem

A user needs to run dbt list -s package:upstream_project+ even if they have intentionally chosen to depend on upstream_project as a "project" rather than a "package". This can lead to confusion.

Solution

This PR implements support for the project: method as an alias for package: in node selection, but with a filter applied to only include public models from the upstream project.

The implementation:

  1. Adds logic to detect when the project: method is used
  2. Applies the existing package: selection logic
  3. Adds a filter to only return nodes that are marked with access='public'

This provides a more intuitive experience for users of dbt Mesh who establish project-type dependencies. Now, instead of having to use package:upstream_project+, users can use project:upstream_project+ which matches the dependency type they've defined.

Manual testing confirms the feature correctly filters out protected and private models while allowing public models through.

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.

@smeyerre smeyerre requested a review from a team as a code owner March 18, 2025 21:02
@cla-bot cla-bot bot added the cla:yes label Mar 18, 2025
@github-actions github-actions bot added the community This PR is from a community member label Mar 18, 2025
@smeyerre
Copy link
Author

First time contributing here so I'll include my local testing process as well in case I missed anything!

Test Environment Setup

  • Created two test projects:
    • upstream_project: Contains models with explicit access controls
    • my_project: Depends on the upstream project

Test Configuration

upstream_project

Set up models with explicit access controls:

  • public_model.sql with access='public'
  • private_model.sql with access='private'
  • Default example models with protected access

my_project

Created dependencies.yml with project-type dependency:

projects:
  - name: 'upstream_project'

Test Scenarios

Test 1: Package Selection vs Project Selection

Command:

dbt list -s package:upstream_project+

Result:
All models and tests from upstream_project included, regardless of access level.

upstream_project.example.my_first_dbt_model
upstream_project.example.my_second_dbt_model
upstream_project.private_model
upstream_project.public_model
upstream_project.example.not_null_my_first_dbt_model_id
upstream_project.example.not_null_my_second_dbt_model_id
upstream_project.example.unique_my_first_dbt_model_id
upstream_project.example.unique_my_second_dbt_model_id

Command:

dbt list -s project:upstream_project+

Result:
Only public model included.

upstream_project.public_model

Note: The project selector correctly filtered out private and protected models, displaying only the public model. Tests are not included as they do not have an access property.

Test 2: Model Resource Type Verification

Command:

dbt list --resource-type model

Result:

my_project.example.my_first_dbt_model
my_project.example.my_second_dbt_model
upstream_project.example.my_first_dbt_model
upstream_project.example.my_second_dbt_model
upstream_project.private_model
upstream_project.public_model

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla:yes community This PR is from a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[CT-3314] [Feature] Support project as an alias for package selection method
1 participant