Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not require a profile in "dbt deps" (#2231) #2290

Merged
merged 3 commits into from
Apr 2, 2020

Conversation

beckjake
Copy link
Contributor

@beckjake beckjake commented Apr 2, 2020

resolves #2231

Description

In "dbt deps", if a profile cannot be found/loaded, use invalid values instead. The generated rendering context for projects in this case will still contain target, but it will be empty.

This works by overriding all the profile-ish elements of RuntimeConfig if a real profile can't be found. If a real profile is found, deps will use a full RuntimeConfig like previously.

Checklist

  • I have signed the CLA
  • I have run this code in development and it appears to resolve the stated issue
  • This PR includes tests, or tests are not required/relevant for this PR
  • I have updated the CHANGELOG.md and added information about my change to the "dbt next" section.

@cla-bot cla-bot bot added the cla:yes label Apr 2, 2020
@beckjake beckjake requested a review from drewbanin April 2, 2020 14:48
  - remove import cycle
  - works even if adapter class has been loaded but adapter object has not been registered
@beckjake beckjake force-pushed the fix/deps-no-profile-required branch from daa2e07 to f0a4810 Compare April 2, 2020 15:17
Copy link
Contributor

@drewbanin drewbanin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One comment here, but also a question: how would a user actually trigger the attribute error shown in this diff? In my experiments, I'm unable to actually reach that codepath (even if i reference target.user in my packages.yml file)

@@ -171,3 +173,172 @@ def get_metadata(self) -> ManifestMetadata:
project_id=self.hashed_name(),
adapter_type=self.credentials.type
)


class PoisonedCredentials(Credentials):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we s/Poisoned/Unset here? I'm also open to:

  • InvalidConfig
  • NotPresentConfig
  • MissingConfig

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I don't care at all what we call it

@beckjake
Copy link
Contributor Author

beckjake commented Apr 2, 2020

how would a user actually trigger the attribute error shown in this diff

I don't think a user could. I think a code change inside dbt could inadvertently do so, and I'm interested in that not happening silently.

Copy link
Contributor

@drewbanin drewbanin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok - LGTM when the tests are passing

@beckjake beckjake merged commit fb3019f into dev/0.16.1 Apr 2, 2020
@beckjake beckjake deleted the fix/deps-no-profile-required branch April 2, 2020 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants