Feat(result logs): Use three logging levels

[tpilewicz]

resolves #2680

Description

I've added an argument logger_fn to the function print_fancy_output_line of module printer.py, that determines the logging level used to print logs. Then I've used it accordingly where the function is called. Also, I've modified the function get_printable_result from this module to determine a logger_fn from model / seed / snapshot results.

I have not added tests because this module was not tested, and I don't really know how to test logging functions yet. Tell me if you think it is better to add some.

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.

[jtcohen6]

Thanks for this contribution, @tpilewicz!

I'm going to hold off on merging this into the dev/marian-anderson branch, as we're currently in release-candidate phase and will be releasing v0.18.0 very soon.

This is a good change; what's less clear to me is whether it'd be a breaking change for users who deploy dbt via orchestration tools, such as Airflow, that have native behavior corresponding to log levels. Should we wait to merge this until the next minor version (0.19), or would it be okay to include in a patch release? @beckjake I'd be curious to hear your thoughts here.

[beckjake]

Well, first of all, does this actually have any significant change in log level, in the sense of "an error was logged"? I assume that's what airflow looks at.

This adds an error log if there is an ERROR SKIP (if this doesn't log an error already, that seems like a bug!) or if the run is canceled with SIGINT. I think I'm fine with it if this change happens to break someone's airflow environment by causing those two cases to fail when they previously didn't. It does the same for warning on warn results, which seems similarly fine.

I think saying that log levels can only be changed in minor/major revs is a really inconvenient precedent to set. Where does it end? Can we rev dependencies? Change print output? Change error handling?

[beckjake]

This looks good to me! When we figure out the merge situation and get this pointed at appropriate branch, I will ask you to add yourself+this PR to a new Contributors section for that release.

[jtcohen6]

I think saying that log levels can only be changed in minor/major revs is a really inconvenient precedent to set. Where does it end? Can we rev dependencies? Change print output? Change error handling?

Cool, let's pull this into v0.18.1.

[tpilewicz]

Great, thanks for your review guys 😄

[jtcohen6]

Looks + works great! Thanks for the contribution @tpilewicz

[jtcohen6]

Suggested change

	- Specify all three logging levels (`INFO`, `WARNING`, `ERROR`) in result logs for commands `test`, `seed`, `run`, `snapshot` and `source snapshot-freshness`
	- Specify all three logging levels (`INFO`, `WARNING`, `ERROR`) in result logs for commands `test`, `seed`, `run`, `snapshot` and `source snapshot-freshness` ([#2680](https://github.com/fishtown-analytics/dbt/pull/2680), [#2723](https://github.com/fishtown-analytics/dbt/pull/2723))

Could you:

• merge changelog conflicts
• move this entry to v0.18.1
• create a Contributors section
• add yourself!