[Tracking] dbt build command

[leahwicz]

Tracking issue for the generalized dbt build command outlined in issue #2743

• RAT
• Demo
• Ensure produced artifacts (manifest.json, run_results.json, sources.json) make sense
• dbt build: Change the way we handle tests (if parent test fails then don't run non-test children) #3597
• Exclude source snapshot-freshness for now
• dbt build: Parity for flags #3596
• dbt build: Add to RPC server #3595
• Additional resource types (~1 left)
• dbt build: Correct non-fast-failing behavior to match other tasks such as run #3598

~~ - [ ] Refactor cmd line library ~~ --> still a smart thing to do, but not needed for this effort

[jtcohen6]

Parity for flags

Ideal is that build supports the superset of all flags. If a flag is supported by any one of the sub-tasks, it should be supported by build, too. Tasks that can use the flag, observe it; tasks that can't use it, ignore it.

Flags I'm particularly interested in:

• --full-refresh
• --store-failures
• --state + --defer
• --resource-types (not supported by other tasks, except list, but should be supported by this one IMO)

Ensure produced artifacts (manifest.json, run_results.json, sources.json) make sense

Should dbt build also include dbt docs generate (and produce catalog.json as well)? This one is funny, since it requires looping back through all nodes to recompile and "execute" them (compile SQL + grab metadata, in a way that varies by adapter). I don't think this should be a hard requirement today, it's something we should think more about.

[jtcohen6]

I'm going to close this tracking issue, in favor of keeping #3595, #3596, #3597 open and tagged for the next cycle epic + release milestone. In the future, let's open all tracking issues as epics, which enables us to nest an epic for a specific work-area (e.g. dbt build) inside larger release + cycle epics.