Bump ubuntu from 22.04 to 23.04 (#6865)

* Bump ubuntu from 22.04 to 23.04

Bumps ubuntu from 22.04 to 23.04.

---
updated-dependencies:
- dependency-name: ubuntu
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>

* Add automated changelog yaml from template for bot PR

---------

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Github Build Bot <buildbot@fishtownanalytics.com>

.bumpversion.cfg

@@ -1,9 +1,49 @@
 [bumpversion]
-current_version = 0.7.0
-commit = True
-tag = True
+current_version = 1.5.0a1
 
-[bumpversion:file:setup.py]
+# `parse` allows parsing the version into the parts we need to check.  There are some
+# unnamed groups and that's okay because they do not need to be audited.  If any part
+# of the version passed and does not match the regex, it will fail.
+# expected matches: `1.5.0`, `1.5.0a1`, `1.5.0a1.dev123457+nightly`
+# excepted failures: `1`, `1.5`, `1.5.2-a1`, `text1.5.0`
+parse = (?P<major>[\d]+) # major version number
+	\.(?P<minor>[\d]+) # minor version number
+	\.(?P<patch>[\d]+) # patch version number
+	(((?P<prekind>a|b|rc) # optional pre-release type
+	?(?P<num>[\d]+?)) # optional pre-release version number
+	\.?(?P<nightly>[a-z0-9]+\+[a-z]+)? # optional nightly release indicator
+	)?
+serialize =
+	{major}.{minor}.{patch}{prekind}{num}.{nightly}
+	{major}.{minor}.{patch}{prekind}{num}
+	{major}.{minor}.{patch}
+commit = False
+tag = False
 
-[bumpversion:file:dbt/version.py]
+[bumpversion:part:prekind]
+first_value = a
+optional_value = final
+values =
+	a
+	b
+	rc
+	final
 
+[bumpversion:part:num]
+first_value = 1
+
+[bumpversion:part:nightly]
+
+[bumpversion:file:core/setup.py]
+
+[bumpversion:file:core/dbt/version.py]
+
+[bumpversion:file:plugins/postgres/setup.py]
+
+[bumpversion:file:plugins/postgres/dbt/adapters/postgres/__version__.py]
+
+[bumpversion:file:docker/Dockerfile]
+
+[bumpversion:file:tests/adapter/setup.py]
+
+[bumpversion:file:tests/adapter/dbt/tests/adapter/__version__.py]

.changes/0.0.0.md

@@ -0,0 +1,21 @@
+## Previous Releases
+
+For information on prior major and minor releases, see their changelogs:
+
+
+* [1.4](https://github.com/dbt-labs/dbt-core/blob/1.4.latest/CHANGELOG.md)
+* [1.3](https://github.com/dbt-labs/dbt-core/blob/1.3.latest/CHANGELOG.md)
+* [1.2](https://github.com/dbt-labs/dbt-core/blob/1.2.latest/CHANGELOG.md)
+* [1.1](https://github.com/dbt-labs/dbt-core/blob/1.1.latest/CHANGELOG.md)
+* [1.0](https://github.com/dbt-labs/dbt-core/blob/1.0.latest/CHANGELOG.md)
+* [0.21](https://github.com/dbt-labs/dbt-core/blob/0.21.latest/CHANGELOG.md)
+* [0.20](https://github.com/dbt-labs/dbt-core/blob/0.20.latest/CHANGELOG.md)
+* [0.19](https://github.com/dbt-labs/dbt-core/blob/0.19.latest/CHANGELOG.md)
+* [0.18](https://github.com/dbt-labs/dbt-core/blob/0.18.latest/CHANGELOG.md)
+* [0.17](https://github.com/dbt-labs/dbt-core/blob/0.17.latest/CHANGELOG.md)
+* [0.16](https://github.com/dbt-labs/dbt-core/blob/0.16.latest/CHANGELOG.md)
+* [0.15](https://github.com/dbt-labs/dbt-core/blob/0.15.latest/CHANGELOG.md)
+* [0.14](https://github.com/dbt-labs/dbt-core/blob/0.14.latest/CHANGELOG.md)
+* [0.13](https://github.com/dbt-labs/dbt-core/blob/0.13.latest/CHANGELOG.md)
+* [0.12](https://github.com/dbt-labs/dbt-core/blob/0.12.latest/CHANGELOG.md)
+* [0.11 and earlier](https://github.com/dbt-labs/dbt-core/blob/0.11.latest/CHANGELOG.md)

.changes/README.md

@@ -0,0 +1,53 @@
+# CHANGELOG Automation
+
+We use [changie](https://changie.dev/) to automate `CHANGELOG` generation.  For installation and format/command specifics, see the documentation.
+
+### Quick Tour
+
+- All new change entries get generated under `/.changes/unreleased` as a yaml file
+- `header.tpl.md` contains the contents of the entire CHANGELOG file
+- `0.0.0.md` contains the contents of the footer for the entire CHANGELOG file.  changie looks to be in the process of supporting a footer file the same as it supports a header file.  Switch to that when available.  For now, the 0.0.0 in the file name forces it to the bottom of the changelog no matter what version we are releasing.
+- `.changie.yaml` contains the fields in a change, the format of a single change, as well as the format of the Contributors section for each version.
+
+### Workflow
+
+#### Daily workflow
+Almost every code change we make associated with an issue will require a `CHANGELOG` entry.  After you have created the PR in GitHub, run `changie new` and follow the command prompts to generate a yaml file with your change details.  This only needs to be done once per PR.
+
+The `changie new` command will ensure correct file format and file name.  There is a one to one mapping of issues to changes.  Multiple issues cannot be lumped into a single entry. If you make a mistake, the yaml file may be directly modified and saved as long as the format is preserved.
+
+Note: If your PR has been cleared by the Core Team as not needing a changelog entry, the `Skip Changelog` label may be put on the PR to bypass the GitHub action that blacks PRs from being merged when they are missing a `CHANGELOG` entry.
+
+#### Prerelease Workflow
+These commands batch up changes in `/.changes/unreleased` to be included in this prerelease and move those files to a directory named for the release version.  The `--move-dir` will be created if it does not exist and is created in `/.changes`.
+
+```
+changie batch <version>  --move-dir '<version>' --prerelease 'rc1'
+changie merge
+```
+
+Example
+```
+changie batch 1.0.5  --move-dir '1.0.5' --prerelease 'rc1'
+changie merge
+```
+
+#### Final Release Workflow
+These commands batch up changes in `/.changes/unreleased` as well as `/.changes/<version>` to be included in this final release and delete all prereleases.  This rolls all prereleases up into a single final release.  All `yaml` files in `/unreleased` and `<version>` will be deleted at this point.
+
+```
+changie batch <version>  --include '<version>' --remove-prereleases
+changie merge
+```
+
+Example
+```
+changie batch 1.0.5  --include '1.0.5' --remove-prereleases
+changie merge
+```
+
+### A Note on Manual Edits & Gotchas
+- Changie generates markdown files in the `.changes` directory that are parsed together with the `changie merge` command.  Every time `changie merge` is run, it regenerates the entire file.  For this reason, any changes made directly to `CHANGELOG.md` will be overwritten on the next run of `changie merge`.
+- If changes need to be made to the `CHANGELOG.md`, make the changes to the relevant `<version>.md` file located in the `/.changes` directory.  You will then run `changie merge` to regenerate the `CHANGELOG.MD`.
+- Do not run `changie batch` again on released versions.  Our final release workflow deletes all of the yaml files associated with individual changes.  If for some reason modifications to the `CHANGELOG.md` are required after we've generated the final release `CHANGELOG.md`, the modifications need to be done manually to the `<version>.md` file in the `/.changes` directory.
+- changie can modify, create and delete files depending on the command you run.  This is expected.  Be sure to commit everything that has been modified and deleted.

.changes/header.tpl.md

@@ -0,0 +1,6 @@
+# dbt Core Changelog
+
+- This file provides a full account of all changes to `dbt-core` and `dbt-postgres`
+- Changes are listed under the (pre)release in which they first appear. Subsequent releases include changes from previous releases.
+- "Breaking changes" listed under a version may require action from end users or external maintainers when upgrading to that version.
+- Do not edit this file directly. This file is auto-generated using [changie](https://github.com/miniscruff/changie). For details on how to document a change, see [the contributing guide](https://github.com/dbt-labs/dbt-core/blob/main/CONTRIBUTING.md#adding-changelog-entry)

.changes/unreleased/Dependencies-20230206-000926.yaml

@@ -0,0 +1,6 @@
+kind: "Dependencies"
+body: "Bump ubuntu from 22.04 to 23.04"
+time: 2023-02-06T00:09:26.00000Z
+custom:
+  Author: dependabot[bot]
+  PR: 6865

.changes/unreleased/Docs-20230207-123807.yaml

@@ -0,0 +1,6 @@
+kind: Docs
+body: update link to installation instructions
+time: 2023-02-07T12:38:07.336783-05:00
+custom:
+  Author: ryancharris
+  Issue: None

.changes/unreleased/Docs-20230209-082901.yaml

@@ -0,0 +1,6 @@
+kind: Docs
+body: Fix JSON path to overview docs
+time: 2023-02-09T08:29:01.432616-07:00
+custom:
+  Author: halvorlu
+  Issue: "366"

.changes/unreleased/Features-20230107-003157.yaml

@@ -0,0 +1,6 @@
+kind: Features
+body: Have dbt debug spit out structured json logs with flags enabled.
+time: 2023-01-07T00:31:57.516063-08:00
+custom:
+  Author: versusfacit
+  Issue: "5353"

.changes/unreleased/Features-20230118-233801.yaml

@@ -0,0 +1,6 @@
+kind: Features
+body: add adapter_response to dbt test and freshness result
+time: 2023-01-18T23:38:01.857342+08:00
+custom:
+  Author: aezomz
+  Issue: "2964"

.changes/unreleased/Features-20230120-112921.yaml

@@ -0,0 +1,6 @@
+kind: Features
+body: Improve error message for packages missing `dbt_project.yml`
+time: 2023-01-20T11:29:21.509967-07:00
+custom:
+  Author: dbeatty10
+  Issue: "6663"

.changes/unreleased/Features-20230126-154716.yaml

@@ -0,0 +1,6 @@
+kind: Features
+body: Adjust makefile to have clearer instructions for CI env var changes.
+time: 2023-01-26T15:47:16.887327-08:00
+custom:
+  Author: versusfacit
+  Issue: "6689"

.changes/unreleased/Features-20230127-162812.yaml

@@ -0,0 +1,6 @@
+kind: Features
+body: Stand-alone Python module for PostgresColumn
+time: 2023-01-27T16:28:12.212427-08:00
+custom:
+  Author: nssalian
+  Issue: "6772"

.changes/unreleased/Fixes-20230116-123645.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: Respect quoting config for dbt.ref(), dbt.source(), and dbt.this() in dbt-py models
+time: 2023-01-16T12:36:45.63092+01:00
+custom:
+  Author: jtcohen6
+  Issue: 6103 6619

.changes/unreleased/Fixes-20230117-101342.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: Provide backward compatibility for `get_merge_sql` arguments
+time: 2023-01-17T10:13:42.118336-06:00
+custom:
+  Author: dave-connors-3
+  Issue: "6625"

.changes/unreleased/Fixes-20230123-132814.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: add merge_exclude_columns adapter tests
+time: 2023-01-23T13:28:14.808748-06:00
+custom:
+  Author: dave-connors-3
+  Issue: "6699"

.changes/unreleased/Fixes-20230124-115837.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: Include adapter_response in NodeFinished run_result log event
+time: 2023-01-24T11:58:37.74179-05:00
+custom:
+  Author: gshank
+  Issue: "6703"

.changes/unreleased/Fixes-20230124-141943.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: Sort cli vars before hashing for partial parsing
+time: 2023-01-24T14:19:43.333628-05:00
+custom:
+  Author: gshank
+  Issue: "6710"

.changes/unreleased/Fixes-20230125-191739.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: '[Regression] exposure_content referenced incorrectly'
+time: 2023-01-25T19:17:39.942081-05:00
+custom:
+  Author: Mathyoub
+  Issue: "6738"

.changes/unreleased/Fixes-20230201-154418.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: Remove pin on packaging and stop using it for prerelease comparisons
+time: 2023-02-01T15:44:18.279158-05:00
+custom:
+  Author: gshank
+  Issue: "6834"

.changes/unreleased/Fixes-20230203-135557.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: Readd depends_on.macros to SeedNode, to support seeds with hooks calling macros
+time: 2023-02-03T13:55:57.853715+01:00
+custom:
+  Author: jtcohen6
+  Issue: "6806"

.changes/unreleased/Fixes-20230207-143544.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: Fix regression of --quiet cli parameter behavior
+time: 2023-02-07T14:35:44.160163-05:00
+custom:
+  Author: peterallenwebb
+  Issue: "6749"

.changes/unreleased/Fixes-20230208-110551.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: Ensure results from hooks contain nodes when processing them
+time: 2023-02-08T11:05:51.952494-06:00
+custom:
+  Author: emmyoop
+  Issue: "6796"

.changes/unreleased/Fixes-20230208-154935.yaml

@@ -0,0 +1,6 @@
+kind: Fixes
+body: Always flush stdout after logging
+time: 2023-02-08T15:49:35.175874-05:00
+custom:
+  Author: peterallenwebb
+  Issue: "6901"

.changes/unreleased/Under the Hood-20230113-132513.yaml

@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: Fix use of ConnectionReused logging event
+time: 2023-01-13T13:25:13.023168-05:00
+custom:
+  Author: gshank
+  Issue: "6168"

.changes/unreleased/Under the Hood-20230113-150700.yaml

@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: Port docs tests to pytest
+time: 2023-01-13T15:07:00.477038-05:00
+custom:
+  Author: peterallenwebb
+  Issue: "6573"

.changes/unreleased/Under the Hood-20230117-111737.yaml

@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: Update deprecated github action command
+time: 2023-01-17T11:17:37.046095-06:00
+custom:
+  Author: davidbloss
+  Issue: "6153"

.changes/unreleased/Under the Hood-20230120-172254.yaml

@@ -0,0 +1,7 @@
+kind: Under the Hood
+body: Replaced the EmptyLine event with a more general Formatting event, and added
+  a Note event.
+time: 2023-01-20T17:22:54.45828-05:00
+custom:
+  Author: peterallenwebb
+  Issue: "6481"

.changes/unreleased/Under the Hood-20230122-215235.yaml

@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: Small optimization on manifest parsing benefitting large DAGs
+time: 2023-01-22T21:52:35.549814+01:00
+custom:
+  Author: boxysean
+  Issue: "6697"

.changes/unreleased/Under the Hood-20230124-153553.yaml

@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: Revised and simplified various structured logging events
+time: 2023-01-24T15:35:53.065356-05:00
+custom:
+  Author: peterallenwebb
+  Issue: 6664 6665 6666

.changes/unreleased/Under the Hood-20230126-135939.yaml

@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: ' Optimized GraphQueue to remove graph analysis bottleneck in large dags.'
+time: 2023-01-26T13:59:39.518345-05:00
+custom:
+  Author: peterallenwebb
+  Issue: "6759"

.changes/unreleased/Under the Hood-20230126-164741.yaml

@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: '[CT-1841] Convert custom target test to Pytest'
+time: 2023-01-26T16:47:41.198714-08:00
+custom:
+  Author: aranke
+  Issue: "6638"

.changes/unreleased/Under the Hood-20230203-143551.yaml

@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: Moving simple_seed to adapter zone to help adapter test conversions
+time: 2023-02-03T14:35:51.481856-08:00
+custom:
+  Author: nssalian
+  Issue: CT-1959

.changie.yaml

@@ -0,0 +1,133 @@
+changesDir: .changes
+unreleasedDir: unreleased
+headerPath: header.tpl.md
+versionHeaderPath: ""
+changelogPath: CHANGELOG.md
+versionExt: md
+versionFormat: '## dbt-core {{.Version}} - {{.Time.Format "January 02, 2006"}}'
+kindFormat: '### {{.Kind}}'
+changeFormat: |-
+  {{- $IssueList := list }}
+  {{- $changes := splitList " " $.Custom.Issue }}
+  {{- range $issueNbr := $changes }}
+    {{- $changeLink := "[#nbr](https://github.com/dbt-labs/dbt-core/issues/nbr)" | replace "nbr" $issueNbr }}
+    {{- $IssueList = append $IssueList $changeLink  }}
+  {{- end -}}
+  - {{.Body}} ({{ range $index, $element := $IssueList }}{{if $index}}, {{end}}{{$element}}{{end}})
+
+kinds:
+  - label: Breaking Changes
+  - label: Features
+  - label: Fixes
+  - label: Docs
+    changeFormat: |-
+      {{- $IssueList := list }}
+      {{- $changes := splitList " " $.Custom.Issue }}
+      {{- range $issueNbr := $changes }}
+        {{- $changeLink := "[dbt-docs/#nbr](https://github.com/dbt-labs/dbt-docs/issues/nbr)" | replace "nbr" $issueNbr }}
+        {{- $IssueList = append $IssueList $changeLink }}
+      {{- end -}}
+      - {{.Body}} ({{ range $index, $element := $IssueList }}{{if $index}}, {{end}}{{$element}}{{end}})
+  - label: Under the Hood
+  - label: Dependencies
+    changeFormat: |-
+      {{- $PRList := list }}
+      {{- $changes := splitList " " $.Custom.PR }}
+      {{- range $pullrequest := $changes }}
+        {{- $changeLink := "[#nbr](https://github.com/dbt-labs/dbt-core/pull/nbr)" | replace "nbr" $pullrequest }}
+        {{- $PRList = append $PRList $changeLink  }}
+      {{- end -}}
+      - {{.Body}} ({{ range $index, $element := $PRList }}{{if $index}}, {{end}}{{$element}}{{end}})
+    skipGlobalChoices: true
+    additionalChoices:
+      - key: Author
+        label: GitHub Username(s) (separated by a single space if multiple)
+        type: string
+        minLength: 3
+      - key: PR
+        label: GitHub Pull Request Number (separated by a single space if multiple)
+        type: string
+        minLength: 1
+  - label: Security
+    changeFormat: |-
+      {{- $PRList := list }}
+      {{- $changes := splitList " " $.Custom.PR }}
+      {{- range $pullrequest := $changes }}
+        {{- $changeLink := "[#nbr](https://github.com/dbt-labs/dbt-core/pull/nbr)" | replace "nbr" $pullrequest }}
+        {{- $PRList = append $PRList $changeLink  }}
+      {{- end -}}
+      - {{.Body}} ({{ range $index, $element := $PRList }}{{if $index}}, {{end}}{{$element}}{{end}})
+    skipGlobalChoices: true
+    additionalChoices:
+      - key: Author
+        label: GitHub Username(s) (separated by a single space if multiple)
+        type: string
+        minLength: 3
+      - key: PR
+        label: GitHub Pull Request Number (separated by a single space if multiple)
+        type: string
+        minLength: 1
+
+newlines:
+  afterChangelogHeader: 1
+  afterKind: 1
+  afterChangelogVersion: 1
+  beforeKind: 1
+  endOfVersion: 1
+
+custom:
+- key: Author
+  label: GitHub Username(s) (separated by a single space if multiple)
+  type: string
+  minLength: 3
+- key: Issue
+  label: GitHub Issue Number (separated by a single space if multiple)
+  type: string
+  minLength: 1
+
+footerFormat: |
+  {{- $contributorDict := dict }}
+  {{- /* any names added to this list should be all lowercase for later matching purposes */}}
+  {{- $core_team := list "michelleark" "peterallenwebb" "emmyoop" "nathaniel-may" "gshank" "leahwicz" "chenyulinx" "stu-k" "iknox-fa" "versusfacit" "mcknight-42" "jtcohen6" "aranke" "dependabot[bot]" "snyk-bot" "colin-rogers-dbt" }}
+  {{- range $change := .Changes }}
+    {{- $authorList := splitList " " $change.Custom.Author }}
+    {{- /* loop through all authors for a single changelog */}}
+    {{- range $author := $authorList }}
+      {{- $authorLower := lower $author }}
+      {{- /* we only want to include non-core team contributors */}}
+      {{- if not (has $authorLower $core_team)}}
+        {{- $changeList := splitList " " $change.Custom.Author }}
+          {{- $IssueList := list }}
+          {{- $changeLink := $change.Kind }}
+          {{- if or (eq $change.Kind "Dependencies") (eq $change.Kind "Security") }}
+            {{- $changes := splitList " " $change.Custom.PR }}
+            {{- range $issueNbr := $changes }}
+              {{- $changeLink := "[#nbr](https://github.com/dbt-labs/dbt-core/pull/nbr)" | replace "nbr" $issueNbr }}
+              {{- $IssueList = append $IssueList $changeLink  }}
+            {{- end -}}
+          {{- else }}
+            {{- $changes := splitList " " $change.Custom.Issue }}
+            {{- range $issueNbr := $changes }}
+              {{- $changeLink := "[#nbr](https://github.com/dbt-labs/dbt-core/issues/nbr)" | replace "nbr" $issueNbr }}
+              {{- $IssueList = append $IssueList $changeLink  }}
+            {{- end -}}
+          {{- end }}
+          {{- /* check if this contributor has other changes associated with them already */}}
+          {{- if hasKey $contributorDict $author }}
+            {{- $contributionList := get $contributorDict $author }}
+            {{- $contributionList = concat $contributionList $IssueList  }}
+            {{- $contributorDict := set $contributorDict $author $contributionList }}
+          {{- else }}
+            {{- $contributionList := $IssueList }}
+            {{- $contributorDict := set $contributorDict $author $contributionList }}
+          {{- end }}
+        {{- end}}
+    {{- end}}
+  {{- end }}
+  {{- /* no indentation here for formatting so the final markdown doesn't have unneeded indentations */}}
+  {{- if $contributorDict}}
+  ### Contributors
+  {{- range $k,$v := $contributorDict }}
+  - [@{{$k}}](https://github.com/{{$k}}) ({{ range $index, $element := $v }}{{if $index}}, {{end}}{{$element}}{{end}})
+  {{- end }}
+  {{- end }}

.coveragerc

@@ -1,3 +0,0 @@
-[report]
-include =
-  dbt/*

.dockerignore

@@ -0,0 +1,3 @@
+*
+!docker/requirements/*.txt
+!dist

.flake8

@@ -0,0 +1,12 @@
+[flake8]
+select =
+    E
+    W
+    F
+ignore =
+    W503 # makes Flake8 work like black
+    W504
+    E203 # makes Flake8 work like black
+    E741
+    E501 # long line checking is done in black
+exclude = test/

.git-blame-ignore-revs

@@ -0,0 +1,2 @@
+# Reformatting dbt-core via black, flake8, mypy, and assorted pre-commit hooks.
+43e3fc22c4eae4d3d901faba05e33c40f1f1dc5a

.gitattributes

@@ -0,0 +1,2 @@
+core/dbt/include/index.html binary
+tests/functional/artifacts/data/state/*/manifest.json binary

.github/CODEOWNERS

@@ -0,0 +1,75 @@
+# This file contains the code owners for the dbt-core repo.
+# PRs will be automatically assigned for review to the associated
+# team(s) or person(s) that touches any files that are mapped to them.
+#
+# A statement takes precedence over the statements above it so more general
+# assignments are found at the top with specific assignments being lower in
+# the ordering (i.e. catch all assignment should be the first item)
+#
+# Consult GitHub documentation for formatting guidelines:
+# https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#example-of-a-codeowners-file
+
+# As a default for areas with no assignment,
+# the core team as a whole will be assigned
+*       @dbt-labs/core
+
+# Changes to GitHub configurations including Actions
+/.github/ @leahwicz
+
+### LANGUAGE
+
+# Language core modules
+/core/dbt/config/               @dbt-labs/core-language
+/core/dbt/context/              @dbt-labs/core-language
+/core/dbt/contracts/            @dbt-labs/core-language
+/core/dbt/deps/                 @dbt-labs/core-language
+/core/dbt/events/               @dbt-labs/core-language  # structured logging
+/core/dbt/parser/               @dbt-labs/core-language
+
+# Language misc files
+/core/dbt/dataclass_schema.py   @dbt-labs/core-language
+/core/dbt/hooks.py              @dbt-labs/core-language
+/core/dbt/node_types.py         @dbt-labs/core-language
+/core/dbt/semver.py             @dbt-labs/core-language
+
+
+### EXECUTION
+
+# Execution core modules
+/core/dbt/graph/                @dbt-labs/core-execution
+/core/dbt/task/                 @dbt-labs/core-execution
+
+# Execution misc files
+/core/dbt/compilation.py        @dbt-labs/core-execution
+/core/dbt/flags.py              @dbt-labs/core-execution
+/core/dbt/lib.py                @dbt-labs/core-execution
+/core/dbt/main.py               @dbt-labs/core-execution
+/core/dbt/profiler.py           @dbt-labs/core-execution
+/core/dbt/selected_resources.py @dbt-labs/core-execution
+/core/dbt/tracking.py           @dbt-labs/core-execution
+/core/dbt/version.py            @dbt-labs/core-execution
+
+
+### ADAPTERS
+
+# Adapter interface ("base" + "sql" adapter defaults, cache)
+/core/dbt/adapters              @dbt-labs/core-adapters
+
+# Global project (default macros + materializations), starter project
+/core/dbt/include               @dbt-labs/core-adapters
+
+# Postgres plugin
+/plugins/                       @dbt-labs/core-adapters
+
+# Functional tests for adapter plugins
+/tests/adapter                  @dbt-labs/core-adapters
+
+### TESTS
+
+# Overlapping ownership for vast majority of unit + functional tests
+
+# Perf regression testing framework
+# This excludes the test project files itself since those aren't specific
+# framework changes (excluded by not setting an owner next to it- no owner)
+/performance @nathaniel-may
+/performance/projects

.github/ISSUE_TEMPLATE/bug-report.yml

@@ -0,0 +1,97 @@
+name: 🐞 Bug
+description: Report a bug or an issue you've found with dbt
+title: "[Bug] <title>"
+labels: ["bug", "triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to fill out this bug report!
+  - type: checkboxes
+    attributes:
+      label: Is this a new bug in dbt-core?
+      description: >
+        In other words, is this an error, flaw, failure or fault in our software?
+
+        If this is a bug that broke existing functionality that used to work, please open a regression issue.
+        If this is a bug in an adapter plugin, please open an issue in the adapter's repository.
+        If this is a bug experienced while using dbt Cloud, please report to [support](mailto:support@getdbt.com).
+        If this is a request for help or troubleshooting code in your own dbt project, please join our [dbt Community Slack](https://www.getdbt.com/community/join-the-community/) or open a [Discussion question](https://github.com/dbt-labs/docs.getdbt.com/discussions).
+
+        Please search to see if an issue already exists for the bug you encountered.
+      options:
+        - label: I believe this is a new bug in dbt-core
+          required: true
+        - label: I have searched the existing issues, and I could not find an existing issue for this bug
+          required: true
+  - type: textarea
+    attributes:
+      label: Current Behavior
+      description: A concise description of what you're experiencing.
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: Expected Behavior
+      description: A concise description of what you expected to happen.
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: Steps To Reproduce
+      description: Steps to reproduce the behavior.
+      placeholder: |
+        1. In this environment...
+        2. With this config...
+        3. Run '...'
+        4. See error...
+    validations:
+      required: true
+  - type: textarea
+    id: logs
+    attributes:
+      label: Relevant log output
+      description: |
+        If applicable, log output to help explain your problem.
+      render: shell
+    validations:
+      required: false
+  - type: textarea
+    attributes:
+      label: Environment
+      description: |
+        examples:
+          - **OS**: Ubuntu 20.04
+          - **Python**: 3.9.12 (`python3 --version`)
+          - **dbt-core**: 1.1.1 (`dbt --version`)
+      value: |
+        - OS:
+        - Python:
+        - dbt:
+      render: markdown
+    validations:
+      required: false
+  - type: dropdown
+    id: database
+    attributes:
+      label: Which database adapter are you using with dbt?
+      description: If the bug is specific to the database or adapter, please open the issue in that adapter's repository instead
+      multiple: true
+      options:
+        - postgres
+        - redshift
+        - snowflake
+        - bigquery
+        - spark
+        - other (mention it in "Additional Context")
+    validations:
+      required: false
+  - type: textarea
+    attributes:
+      label: Additional Context
+      description: |
+        Links? References? Anything that will give us more context about the issue you are encountering!
+
+        Tip: You can attach images or log files by clicking this area to highlight it and then dragging files in.
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,23 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Ask the community for help
+    url: https://github.com/dbt-labs/docs.getdbt.com/discussions
+    about: Need help troubleshooting? Check out our guide on how to ask
+  - name: Contact dbt Cloud support
+    url: mailto:support@getdbt.com
+    about: Are you using dbt Cloud? Contact our support team for help!
+  - name: Participate in Discussions
+    url: https://github.com/dbt-labs/dbt-core/discussions
+    about: Do you have a Big Idea for dbt? Read open discussions, or start a new one
+  - name: Create an issue for dbt-redshift
+    url: https://github.com/dbt-labs/dbt-redshift/issues/new/choose
+    about: Report a bug or request a feature for dbt-redshift
+  - name: Create an issue for dbt-bigquery
+    url: https://github.com/dbt-labs/dbt-bigquery/issues/new/choose
+    about: Report a bug or request a feature for dbt-bigquery
+  - name: Create an issue for dbt-snowflake
+    url: https://github.com/dbt-labs/dbt-snowflake/issues/new/choose
+    about: Report a bug or request a feature for dbt-snowflake
+  - name: Create an issue for dbt-spark
+    url: https://github.com/dbt-labs/dbt-spark/issues/new/choose
+    about: Report a bug or request a feature for dbt-spark

.github/ISSUE_TEMPLATE/feature-request.yml

@@ -0,0 +1,59 @@
+name: ✨ Feature
+description: Propose a straightforward extension of dbt functionality
+title: "[Feature] <title>"
+labels: ["enhancement", "triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to fill out this feature request!
+  - type: checkboxes
+    attributes:
+      label: Is this your first time submitting a feature request?
+      description: >
+        We want to make sure that features are distinct and discoverable,
+        so that other members of the community can find them and offer their thoughts.
+
+        Issues are the right place to request straightforward extensions of existing dbt functionality.
+        For "big ideas" about future capabilities of dbt, we ask that you open a
+        [discussion](https://github.com/dbt-labs/dbt-core/discussions) in the "Ideas" category instead.
+      options:
+        - label: I have read the [expectations for open source contributors](https://docs.getdbt.com/docs/contributing/oss-expectations)
+          required: true
+        - label: I have searched the existing issues, and I could not find an existing issue for this feature
+          required: true
+        - label: I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion
+          required: true
+  - type: textarea
+    attributes:
+      label: Describe the feature
+      description: A clear and concise description of what you want to happen.
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: Describe alternatives you've considered
+      description: |
+        A clear and concise description of any alternative solutions or features you've considered.
+    validations:
+      required: false
+  - type: textarea
+    attributes:
+      label: Who will this benefit?
+      description: |
+        What kind of use case will this feature be useful for? Please be specific and provide examples, this will help us prioritize properly.
+    validations:
+      required: false
+  - type: input
+    attributes:
+      label: Are you interested in contributing this feature?
+      description: Let us know if you want to write some code, and how we can help.
+    validations:
+      required: false
+  - type: textarea
+    attributes:
+      label: Anything else?
+      description: |
+        Links? References? Anything that will give us more context about the feature you are suggesting!
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/regression-report.yml

@@ -0,0 +1,93 @@
+name: ☣️ Regression
+description: Report a regression you've observed in a newer version of dbt
+title: "[Regression] <title>"
+labels: ["bug", "regression", "triage"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to fill out this regression report!
+  - type: checkboxes
+    attributes:
+      label: Is this a regression in a recent version of dbt-core?
+      description: >
+        A regression is when documented functionality works as expected in an older version of dbt-core,
+        and no longer works after upgrading to a newer version of dbt-core
+      options:
+        - label: I believe this is a regression in dbt-core functionality
+          required: true
+        - label: I have searched the existing issues, and I could not find an existing issue for this regression
+          required: true
+  - type: textarea
+    attributes:
+      label: Current Behavior
+      description: A concise description of what you're experiencing.
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: Expected/Previous Behavior
+      description: A concise description of what you expected to happen.
+    validations:
+      required: true
+  - type: textarea
+    attributes:
+      label: Steps To Reproduce
+      description: Steps to reproduce the behavior.
+      placeholder: |
+        1. In this environment...
+        2. With this config...
+        3. Run '...'
+        4. See error...
+    validations:
+      required: true
+  - type: textarea
+    id: logs
+    attributes:
+      label: Relevant log output
+      description: |
+        If applicable, log output to help explain your problem.
+      render: shell
+    validations:
+      required: false
+  - type: textarea
+    attributes:
+      label: Environment
+      description: |
+        examples:
+          - **OS**: Ubuntu 20.04
+          - **Python**: 3.9.12 (`python3 --version`)
+          - **dbt-core (working version)**: 1.1.1 (`dbt --version`)
+          - **dbt-core (regression version)**: 1.2.0 (`dbt --version`)
+      value: |
+        - OS:
+        - Python:
+        - dbt (working version):
+        - dbt (regression version):
+      render: markdown
+    validations:
+      required: true
+  - type: dropdown
+    id: database
+    attributes:
+      label: Which database adapter are you using with dbt?
+      description: If the regression is specific to the database or adapter, please open the issue in that adapter's repository instead
+      multiple: true
+      options:
+        - postgres
+        - redshift
+        - snowflake
+        - bigquery
+        - spark
+        - other (mention it in "Additional Context")
+    validations:
+      required: false
+  - type: textarea
+    attributes:
+      label: Additional Context
+      description: |
+        Links? References? Anything that will give us more context about the issue you are encountering!
+
+        Tip: You can attach images or log files by clicking this area to highlight it and then dragging files in.
+    validations:
+      required: false

.github/_README.md

@@ -0,0 +1,216 @@
+<!-- GitHub will publish this readme on the main repo page if the name is `README.md` so we've added the leading underscore to prevent this -->
+<!-- Do not rename this file `README.md` -->
+<!-- See https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes -->
+
+## What are GitHub Actions?
+
+GitHub Actions are used for many different purposes.  We use them to run tests in CI, validate PRs are in an expected state, and automate processes.
+
+- [Overview of GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions)
+- [What's a workflow?](https://docs.github.com/en/actions/using-workflows/about-workflows)
+- [GitHub Actions guides](https://docs.github.com/en/actions/guides)
+
+___
+
+## Where do actions and workflows live
+
+We try to maintain actions that are shared across repositories in a single place so that necesary changes can be made in a single place.
+
+[dbt-labs/actions](https://github.com/dbt-labs/actions/) is the central repository of actions and workflows we use across repositories.
+
+GitHub Actions also live locally within a repository.  The workflows can be found at `.github/workflows` from the root of the repository.  These should be specific to that code base.
+
+Note: We are actively moving actions into the central Action repository so there is currently some duplication across repositories.
+
+___
+
+## Basics of Using Actions
+
+### Viewing Output
+
+- View the detailed action output for your PR in the **Checks** tab of the PR.  This only shows the most recent run.  You can also view high level **Checks** output at the bottom on the PR.
+
+- View _all_ action output for a repository from the [**Actions**](https://github.com/dbt-labs/dbt-core/actions) tab.  Workflow results last 1 year.  Artifacts last 90 days, unless specified otherwise in individual workflows.
+
+  This view often shows what seem like duplicates of the same workflow.  This occurs when files are renamed but the workflow name has not changed.  These are in fact _not_ duplicates.
+
+  You can see the branch the workflow runs from in this view.  It is listed in the table between the workflow name and the time/duration of the run.  When blank, the workflow is running in the context of the  `main` branch.
+
+### How to view what workflow file is being referenced from a run
+
+- When viewing the output of a specific workflow run, click the 3 dots at the top right of the display.  There will be an option to `View workflow file`.
+
+### How to manually run a workflow
+
+- If a workflow has the `on: workflow_dispatch` trigger, it can be manually triggered
+- From the [**Actions**](https://github.com/dbt-labs/dbt-core/actions) tab, find the workflow you want to run, select it and fill in any inputs requied.  That's it!
+
+### How to re-run jobs
+
+- Some actions cannot be rerun in the GitHub UI.  Namely the snyk checks and the cla check.  Snyk checks are rerun by closing and reopening the PR.  You can retrigger the cla check by commenting on the PR with `@cla-bot check`
+
+___
+
+## General Standards
+
+### Permissions
+- By default, workflows have read permissions in the repository for the contents scope only when no permissions are explicitly set.
+- It is best practice to always define the permissions explicitly.  This will allow actions to continue to work when the default permissions on the repository are changed.  It also allows explicit grants of the least permissions possible.
+- There are a lot of permissions available.  [Read up on them](https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs) if you're unsure what to use.
+
+```yaml
+permissions:
+  contents: read
+  pull-requests: write
+```
+
+### Secrets
+- When to use a [Personal Access Token (PAT)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) vs the [GITHUB_TOKEN](https://docs.github.com/en/actions/security-guides/automatic-token-authentication) generated for the action?
+
+    The `GITHUB_TOKEN` is used by default.  In most cases it is sufficient for what you need.
+
+    If you expect the workflow to result in a commit to that should retrigger workflows, you will need to use a Personal Access Token for the bot to commit the file. When using the GITHUB_TOKEN, the resulting commit will not trigger another GitHub Actions Workflow run. This is due to limitations set by GitHub. See [the docs](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow) for a more detailed explanation.
+
+    For example, we must use a PAT in our workflow to commit a new changelog yaml file for bot PRs.  Once the file has been committed to the branch, it should retrigger the check to validate that a changelog exists on the PR.  Otherwise, it would stay in a failed state since the check would never retrigger.
+
+### Triggers
+You can configure your workflows to run when specific activity on GitHub happens, at a scheduled time, or when an event outside of GitHub occurs.  Read more details in the [GitHub docs](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows).
+
+These triggers are under the `on` key of the workflow and more than one can be listed.
+
+```yaml
+on:
+  push:
+    branches:
+      - "main"
+      - "*.latest"
+      - "releases/*"
+  pull_request:
+    # catch when the PR is opened with the label or when the label is added
+    types: [opened, labeled]
+  workflow_dispatch:
+```
+
+Some triggers of note that we use:
+
+- `push` - Runs your workflow when you push a commit or tag.
+- `pull_request` - Runs your workflow when activity on a pull request in the workflow's repository occurs.  Takes in a list of activity types (opened, labeled, etc) if appropriate.
+- `pull_request_target` - Same as `pull_request` but runs in the context of the PR target branch.
+- `workflow_call` - used with reusable workflows.  Triggered by another workflow calling it.
+- `workflow_dispatch` - Gives the ability to manually trigger a workflow from the GitHub API, GitHub CLI, or GitHub browser interface.
+
+
+### Basic Formatting
+- Add a description of what your workflow does at the top in this format
+
+  ```
+  # **what?**
+  # Describe what the action does.
+
+  # **why?**
+  # Why does this action exist?
+
+  # **when?**
+  # How/when will it be triggered?
+  ```
+
+- Leave blank lines between steps and jobs
+
+  ```yaml
+  jobs:
+    dependency_changelog:
+      runs-on: ubuntu-latest
+
+      steps:
+      - name: Get File Name Timestamp
+        id: filename_time
+        uses: nanzm/get-time-action@v1.1
+        with:
+          format: 'YYYYMMDD-HHmmss'
+
+      - name: Get File Content Timestamp
+        id: file_content_time
+        uses: nanzm/get-time-action@v1.1
+        with:
+          format: 'YYYY-MM-DDTHH:mm:ss.000000-05:00'
+
+      - name: Generate Filepath
+        id: fp
+        run: |
+          FILEPATH=.changes/unreleased/Dependencies-${{ steps.filename_time.outputs.time }}.yaml
+          echo "FILEPATH=$FILEPATH" >> $GITHUB_OUTPUT
+  ```
+
+- Print out all variables you will reference as the first step of a job.  This allows for easier debugging.  The first job should log all inputs.  Subsequent jobs should reference outputs of other jobs, if present.
+
+  When possible, generate variables at the top of your workflow in a single place to reference later.  This is not always strictly possible since you may generate a value to be used later mid-workflow.
+
+  Be sure to use quotes around these logs so special characters are not interpreted.
+
+  ```yaml
+  job1:
+    - name: "[DEBUG] Print Variables"
+      run: |
+        echo "all variables defined as inputs"
+        echo "The last commit sha in the release: ${{ inputs.sha }}"
+        echo "The release version number:         ${{ inputs.version_number }}"
+        echo "The changelog_path:                 ${{ inputs.changelog_path }}"
+        echo "The build_script_path:              ${{ inputs.build_script_path }}"
+        echo "The s3_bucket_name:                 ${{ inputs.s3_bucket_name }}"
+        echo "The package_test_command:           ${{ inputs.package_test_command }}"
+
+    # collect all the variables that need to be used in subsequent jobs
+    - name: Set Variables
+      id: variables
+      run: |
+        echo "important_path='performance/runner/Cargo.toml'" >> $GITHUB_OUTPUT
+        echo "release_id=${{github.event.inputs.release_id}}" >> $GITHUB_OUTPUT
+        echo "open_prs=${{github.event.inputs.open_prs}}" >> $GITHUB_OUTPUT
+
+  job2:
+    needs: [job1]
+      - name: "[DEBUG] Print Variables"
+      run: |
+        echo "all variables defined in job1 > Set Variables > outputs"
+        echo "important_path: ${{ needs.job1.outputs.important_path }}"
+        echo "release_id:     ${{ needs.job1.outputs.release_id }}"
+        echo "open_prs:       ${{ needs.job1.outputs.open_prs }}"
+  ```
+
+- When it's not obvious what something does, add a comment!
+
+___
+
+## Tips
+
+### Context
+- The [GitHub CLI](https://cli.github.com/) is available in the default runners
+- Actions run in your context.  ie, using an action from the marketplace that uses the GITHUB_TOKEN uses the GITHUB_TOKEN generated by your workflow run.
+
+### Actions from the Marketplace
+- Don’t use external actions for things that can easily be accomplished manually.
+- Always read through what an external action does before using it!  Often an action in the GitHub Actions Marketplace can be replaced with a few lines in bash.  This is much more maintainable (and won’t change under us) and clear as to what’s actually happening.  It also prevents any
+- Pin actions _we don't control_ to tags.
+
+### Connecting to AWS
+- Authenticate with the aws managed workflow
+
+  ```yaml
+  - name: Configure AWS credentials from Test account
+    uses: aws-actions/configure-aws-credentials@v1
+    with:
+      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
+      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+      aws-region: us-east-1
+  ```
+
+- Then access with the aws command that comes installed on the action runner machines
+
+  ```yaml
+  - name: Copy Artifacts from S3 via CLI
+    run: aws s3 cp ${{ env.s3_bucket }} . --recursive
+  ```
+
+### Testing
+
+- Depending on what your action does, you may be able to use [`act`](https://github.com/nektos/act) to test the action locally.  Some features of GitHub Actions do not work with `act`, among those are reusable workflows.  If you can't use `act`, you'll have to push your changes up before being able to test.  This can be slow.

.github/actions/latest-wrangler/Dockerfile

@@ -0,0 +1,14 @@
+FROM python:3-slim AS builder
+ADD . /app
+WORKDIR /app
+
+# We are installing a dependency here directly into our app source dir
+RUN pip install --target=/app requests packaging
+
+# A distroless container image with Python and some basics like SSL certificates
+# https://github.com/GoogleContainerTools/distroless
+FROM gcr.io/distroless/python3-debian10
+COPY --from=builder /app /app
+WORKDIR /app
+ENV PYTHONPATH /app
+CMD ["/app/main.py"]

.github/actions/latest-wrangler/README.md

@@ -0,0 +1,50 @@
+# Github package 'latest' tag wrangler for containers
+## Usage
+
+Plug in the necessary inputs to determine if the container being built should be tagged 'latest; at the package level, for example `dbt-redshift:latest`.
+
+## Inputs
+| Input | Description |
+| - | - |
+| `package` | Name of the GH package to check against |
+| `new_version` | Semver of new container |
+| `gh_token` | GH token with package read scope|
+| `halt_on_missing` | Return non-zero exit code if requested package does not exist. (defaults to false)|
+
+
+## Outputs
+| Output | Description |
+| - | - |
+| `latest` | Wether or not the new container should be tagged 'latest'|
+| `minor_latest` | Wether or not the new container should be tagged major.minor.latest |
+
+## Example workflow
+```yaml
+name: Ship it!
+on:
+  workflow_dispatch:
+    inputs:
+      package:
+       description: The package to publish
+       required: true
+      version_number:
+       description: The version number
+       required: true
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v1
+    - name: Wrangle latest tag
+      id: is_latest
+      uses: ./.github/actions/latest-wrangler
+      with:
+        package: ${{ github.event.inputs.package }}
+        new_version: ${{ github.event.inputs.new_version }}
+        gh_token: ${{ secrets.GITHUB_TOKEN }}
+    - name: Print the results
+      run: |
+        echo "Is it latest?  Survey says: ${{ steps.is_latest.outputs.latest }} !"
+        echo "Is it minor.latest?  Survey says: ${{ steps.is_latest.outputs.minor_latest }} !"
+```

.github/actions/latest-wrangler/action.yml

@@ -0,0 +1,20 @@
+name: "Github package 'latest' tag wrangler for containers"
+description: "Determines wether or not a given dbt container should be given a bare 'latest' tag (I.E. dbt-core:latest)"
+inputs:
+  package_name:
+    description: "Package to check (I.E. dbt-core, dbt-redshift, etc)"
+    required: true
+  new_version:
+    description: "Semver of the container being built (I.E. 1.0.4)"
+    required: true
+  gh_token:
+    description: "Auth token for github (must have view packages scope)"
+    required: true
+outputs:
+  latest:
+    description: "Wether or not built container should be tagged latest (bool)"
+  minor_latest:
+    description: "Wether or not built container should be tagged minor.latest (bool)"
+runs:
+  using: "docker"
+  image: "Dockerfile"

.github/actions/latest-wrangler/examples/example_workflow.yml

@@ -0,0 +1,26 @@
+name: Ship it!
+on:
+  workflow_dispatch:
+    inputs:
+      package:
+       description: The package to publish
+       required: true
+      version_number:
+       description: The version number
+       required: true
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v1
+    - name: Wrangle latest tag
+      id: is_latest
+      uses: ./.github/actions/latest-wrangler
+      with:
+        package: ${{ github.event.inputs.package }}
+        new_version: ${{ github.event.inputs.new_version }}
+        gh_token: ${{ secrets.GITHUB_TOKEN }}
+    - name: Print the results
+      run: |
+        echo "Is it latest?  Survey says: ${{ steps.is_latest.outputs.latest }} !"

.github/actions/latest-wrangler/examples/example_workflow_dispatch.json

@@ -0,0 +1,6 @@
+{
+    "inputs": {
+      "version_number": "1.0.1",
+      "package": "dbt-redshift"
+    }
+}

.github/actions/latest-wrangler/main.py

@@ -0,0 +1,98 @@
+import os
+import sys
+import requests
+from distutils.util import strtobool
+from typing import Union
+from packaging.version import parse, Version
+
+if __name__ == "__main__":
+
+    # get inputs
+    package = os.environ["INPUT_PACKAGE"]
+    new_version = parse(os.environ["INPUT_NEW_VERSION"])
+    gh_token = os.environ["INPUT_GH_TOKEN"]
+    halt_on_missing = strtobool(os.environ.get("INPUT_HALT_ON_MISSING", "False"))
+
+    # get package metadata from github
+    package_request = requests.get(
+        f"https://api.github.com/orgs/dbt-labs/packages/container/{package}/versions",
+        auth=("", gh_token),
+    )
+    package_meta = package_request.json()
+
+    # Log info if we don't get a 200
+    if package_request.status_code != 200:
+        print(f"Call to GH API failed: {package_request.status_code} {package_meta['message']}")
+
+    # Make an early exit if there is no matching package in github
+    if package_request.status_code == 404:
+        if halt_on_missing:
+            sys.exit(1)
+        # everything is the latest if the package doesn't exist
+        github_output = os.environ.get("GITHUB_OUTPUT")
+        with open(github_output, "at", encoding="utf-8") as gh_output:
+            gh_output.write("latest=True")
+            gh_output.write("minor_latest=True")
+        sys.exit(0)
+
+    # TODO: verify package meta is "correct"
+    # https://github.com/dbt-labs/dbt-core/issues/4640
+
+    # map versions and tags
+    version_tag_map = {
+        version["id"]: version["metadata"]["container"]["tags"] for version in package_meta
+    }
+
+    # is pre-release
+    pre_rel = True if any(x in str(new_version) for x in ["a", "b", "rc"]) else False
+
+    # semver of current latest
+    for version, tags in version_tag_map.items():
+        if "latest" in tags:
+            # N.B. This seems counterintuitive, but we expect any version tagged
+            # 'latest' to have exactly three associated tags:
+            # latest, major.minor.latest, and major.minor.patch.
+            # Subtracting everything that contains the string 'latest' gets us
+            # the major.minor.patch which is what's needed for comparison.
+            current_latest = parse([tag for tag in tags if "latest" not in tag][0])
+        else:
+            current_latest = False
+
+    # semver of current_minor_latest
+    for version, tags in version_tag_map.items():
+        if f"{new_version.major}.{new_version.minor}.latest" in tags:
+            # Similar to above, only now we expect exactly two tags:
+            # major.minor.patch and major.minor.latest
+            current_minor_latest = parse([tag for tag in tags if "latest" not in tag][0])
+        else:
+            current_minor_latest = False
+
+    def is_latest(
+        pre_rel: bool, new_version: Version, remote_latest: Union[bool, Version]
+    ) -> bool:
+        """Determine if a given contaier should be tagged 'latest' based on:
+         - it's pre-release status
+         - it's version
+         - the version of a previously identified container tagged 'latest'
+
+        :param pre_rel: Wether or not the version of the new container is a pre-release
+        :param new_version: The version of the new container
+        :param remote_latest: The version of the previously identified container that's
+            already tagged latest or False
+        """
+        # is a pre-release = not latest
+        if pre_rel:
+            return False
+        # + no latest tag found = is latest
+        if not remote_latest:
+            return True
+        # + if remote version is lower than current = is latest, else not latest
+        return True if remote_latest <= new_version else False
+
+    latest = is_latest(pre_rel, new_version, current_latest)
+    minor_latest = is_latest(pre_rel, new_version, current_minor_latest)
+
+    github_output = os.environ.get("GITHUB_OUTPUT")
+    with open(github_output, "at", encoding="utf-8") as gh_output:
+        gh_output.write(f"latest={latest}")
+        gh_output.write(f"minor_latest={minor_latest}")

.github/actions/setup-postgres-linux/action.yml

@@ -0,0 +1,10 @@
+name: "Set up postgres (linux)"
+description: "Set up postgres service on linux vm for dbt integration tests"
+runs:
+  using: "composite"
+  steps:
+    - shell: bash
+      run: |
+        sudo systemctl start postgresql.service
+        pg_isready
+        sudo -u postgres bash ${{ github.action_path }}/setup_db.sh

.github/actions/setup-postgres-linux/setup_db.sh

@@ -0,0 +1 @@
+../../../test/setup_db.sh

.github/actions/setup-postgres-macos/action.yml

@@ -0,0 +1,24 @@
+name: "Set up postgres (macos)"
+description: "Set up postgres service on macos vm for dbt integration tests"
+runs:
+  using: "composite"
+  steps:
+    - shell: bash
+      run: |
+        brew services start postgresql
+        echo "Check PostgreSQL service is running"
+        i=10
+        COMMAND='pg_isready'
+        while [ $i -gt -1 ]; do
+            if [ $i == 0 ]; then
+                echo "PostgreSQL service not ready, all attempts exhausted"
+                exit 1
+            fi
+            echo "Check PostgreSQL service status"
+            eval $COMMAND && break
+            echo "PostgreSQL service not ready, wait 10 more sec, attempts left: $i"
+            sleep 10
+            ((i--))
+        done
+        createuser -s postgres
+        bash ${{ github.action_path }}/setup_db.sh

.github/actions/setup-postgres-macos/setup_db.sh

@@ -0,0 +1 @@
+../../../test/setup_db.sh

.github/actions/setup-postgres-windows/action.yml

@@ -0,0 +1,12 @@
+name: "Set up postgres (windows)"
+description: "Set up postgres service on windows vm for dbt integration tests"
+runs:
+  using: "composite"
+  steps:
+    - shell: pwsh
+      run: |
+        $pgService = Get-Service -Name postgresql*
+        Set-Service -InputObject $pgService -Status running -StartupType automatic
+        Start-Process -FilePath "$env:PGBIN\pg_isready" -Wait -PassThru
+        $env:Path += ";$env:PGBIN"
+        bash ${{ github.action_path }}/setup_db.sh

.github/actions/setup-postgres-windows/setup_db.sh

@@ -0,0 +1 @@
+../../../test/setup_db.sh

.github/dependabot.yml

@@ -0,0 +1,30 @@
+version: 2
+updates:
+  # python dependencies
+  - package-ecosystem: "pip"
+    directory: "/"
+    schedule:
+      interval: "daily"
+    rebase-strategy: "disabled"
+  - package-ecosystem: "pip"
+    directory: "/core"
+    schedule:
+      interval: "daily"
+    rebase-strategy: "disabled"
+  - package-ecosystem: "pip"
+    directory: "/plugins/postgres"
+    schedule:
+      interval: "daily"
+    rebase-strategy: "disabled"
+
+  # docker dependencies
+  - package-ecosystem: "docker"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    rebase-strategy: "disabled"
+  - package-ecosystem: "docker"
+    directory: "/docker"
+    schedule:
+      interval: "weekly"
+    rebase-strategy: "disabled"

.github/pull_request_template.md

@@ -0,0 +1,23 @@
+resolves #
+
+<!---
+  Include the number of the issue addressed by this PR above if applicable.
+  PRs for code changes without an associated issue *will not be merged*.
+  See CONTRIBUTING.md for more information.
+-->
+
+### Description
+
+<!---
+  Describe the Pull Request here. Add any references and info to help reviewers
+  understand your changes. Include any tradeoffs you considered.
+-->
+
+### Checklist
+
+- [ ] I have read [the contributing guide](https://github.com/dbt-labs/dbt-core/blob/main/CONTRIBUTING.md) and understand what's expected of me
+- [ ] I have signed the [CLA](https://docs.getdbt.com/docs/contributor-license-agreements)
+- [ ] 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 [opened an issue to add/update docs](https://github.com/dbt-labs/docs.getdbt.com/issues/new/choose), or docs changes are not required/relevant for this PR
+- [ ] I have run `changie new` to [create a changelog entry](https://github.com/dbt-labs/dbt-core/blob/main/CONTRIBUTING.md#adding-a-changelog-entry)

.github/workflows/backport.yml

@@ -0,0 +1,40 @@
+# **what?**
+# When a PR is merged, if it has the backport label, it will create
+# a new PR to backport those changes to the given branch. If it can't
+# cleanly do a backport, it will comment on the merged PR of the failure.
+#
+# Label naming convention: "backport <branch name to backport to>"
+# Example: backport 1.0.latest
+#
+# You MUST "Squash and merge" the original PR or this won't work.
+
+# **why?**
+# Changes sometimes need to be backported to release branches.
+# This automates the backporting process
+
+# **when?**
+# Once a PR is "Squash and merge"'d, by adding a backport label, this is triggered
+
+name: Backport
+on:
+  pull_request:
+    types:
+      - labeled
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  backport:
+    name: Backport
+    runs-on: ubuntu-latest
+    # Only react to merged PRs for security reasons.
+    # See https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target.
+    if: >
+      github.event.pull_request.merged
+      && contains(github.event.label.name, 'backport')
+    steps:
+      - uses: tibdex/backport@v2.0.2
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/bot-changelog.yml

@@ -0,0 +1,61 @@
+# **what?**
+# When bots create a PR, this action will add a corresponding changie yaml file to that
+# PR when a specific label is added.
+#
+# The file is created off a template:
+#
+# kind: <per action matrix>
+# body: <PR title>
+# time: <current timestamp>
+# custom:
+#   Author: <PR User Login (generally the bot)>
+#   Issue: 4904
+#   PR: <PR number>
+#
+# **why?**
+# Automate changelog generation for more visability with automated bot PRs.
+#
+# **when?**
+# Once a PR is created, label should be added to PR before or after creation. You can also
+#  manually trigger this by adding the appropriate label at any time.
+#
+# **how to add another bot?**
+# Add the label and changie kind to the include matrix.  That's it!
+#
+
+name: Bot Changelog
+
+on:
+  pull_request:
+    # catch when the PR is opened with the label or when the label is added
+    types: [labeled]
+
+permissions:
+  contents: write
+  pull-requests: read
+
+jobs:
+  generate_changelog:
+    strategy:
+      matrix:
+        include:
+          - label: "dependencies"
+            changie_kind: "Dependencies"
+          - label: "snyk"
+            changie_kind: "Security"
+    runs-on: ubuntu-latest
+
+    steps:
+
+    - name: Create and commit changelog on bot PR
+      if: ${{ contains(github.event.pull_request.labels.*.name, matrix.label) }}
+      id: bot_changelog
+      uses: emmyoop/changie_bot@v1.0.1
+      with:
+        GITHUB_TOKEN: ${{ secrets.FISHTOWN_BOT_PAT }}
+        commit_author_name: "Github Build Bot"
+        commit_author_email: "<buildbot@fishtownanalytics.com>"
+        commit_message: "Add automated changelog yaml from template for bot PR"
+        changie_kind: ${{ matrix.changie_kind }}
+        label: ${{ matrix.label }}
+        custom_changelog_string: "custom:\n  Author: ${{ github.event.pull_request.user.login }}\n  PR: ${{ github.event.pull_request.number }}"

.github/workflows/changelog-existence.yml

@@ -0,0 +1,40 @@
+# **what?**
+# Checks that a file has been committed under the /.changes directory
+# as a new CHANGELOG entry.  Cannot check for a specific filename as
+# it is dynamically generated by change type and timestamp.
+# This workflow should not require any secrets since it runs for PRs
+# from forked repos.
+# By default, secrets are not passed to workflows running from
+# a forked repo.
+
+# **why?**
+# Ensure code change gets reflected in the CHANGELOG.
+
+# **when?**
+# This will run for all PRs going into main and *.latest.  It will
+# run when they are opened, reopened, when any label is added or removed
+# and when new code is pushed to the branch.  The action will then get
+# skipped if the 'Skip Changelog' label is present is any of the labels.
+
+name: Check Changelog Entry
+
+on:
+  pull_request:
+    types: [opened, reopened, labeled, unlabeled, synchronize]
+  workflow_dispatch:
+
+defaults:
+  run:
+    shell: bash
+
+permissions:
+  contents: read
+  pull-requests: write
+
+jobs:
+  changelog:
+    uses: dbt-labs/actions/.github/workflows/changelog-existence.yml@main
+    with:
+      changelog_comment: 'Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see [the contributing guide](https://github.com/dbt-labs/dbt-core/blob/main/CONTRIBUTING.md#adding-changelog-entry).'
+      skip_label: 'Skip Changelog'
+    secrets: inherit

.github/workflows/generate-cli-api-docs.yml

@@ -0,0 +1,165 @@
+# **what?**
+# On push, if anything in core/dbt/docs or core/dbt/cli has been
+# created or modified, regenerate the CLI API docs using sphinx.
+
+# **why?**
+# We watch for changes in core/dbt/cli because the CLI API docs rely on click
+# and all supporting flags/params to be generated. We watch for changes in
+# core/dbt/docs since any changes to sphinx configuration or any of the
+# .rst files there could result in a differently build final index.html file.
+
+# **when?**
+# Whenever a change has been pushed to a branch, and only if there is a diff
+# between the PR branch and main's core/dbt/cli and or core/dbt/docs dirs.
+
+# TODO: add bot comment to PR informing contributor that the docs have been committed
+# TODO: figure out why github action triggered pushes cause github to fail to report
+#       the status of jobs
+
+name: Generate CLI API docs
+
+on:
+  pull_request:
+
+permissions:
+  contents: write
+  pull-requests: write
+
+env:
+  CLI_DIR: ${{ github.workspace }}/core/dbt/cli
+  DOCS_DIR: ${{ github.workspace }}/core/dbt/docs
+  DOCS_BUILD_DIR: ${{ github.workspace }}/core/dbt/docs/build
+
+jobs:
+  check_gen:
+    name: check if generation needed
+    runs-on: ubuntu-latest
+    if: ${{ github.event.pull_request.head.repo.fork == false }}
+    outputs:
+      cli_dir_changed: ${{ steps.check_cli.outputs.cli_dir_changed }}
+      docs_dir_changed: ${{ steps.check_docs.outputs.docs_dir_changed }}
+
+    steps:
+    - name: "[DEBUG] print variables"
+      run: |
+        echo "env.CLI_DIR:        ${{ env.CLI_DIR }}"
+        echo "env.DOCS_BUILD_DIR: ${{ env.DOCS_BUILD_DIR }}"
+        echo "env.DOCS_DIR:       ${{ env.DOCS_DIR }}"
+
+    - name: git checkout
+      uses: actions/checkout@v3
+      with:
+        fetch-depth: 0
+        ref: ${{ github.head_ref }}
+
+    - name: set shas
+      id: set_shas
+      run: |
+        THIS_SHA=$(git rev-parse @)
+        LAST_SHA=$(git rev-parse @~1)
+
+        echo "this sha: $THIS_SHA"
+        echo "last sha: $LAST_SHA"
+
+        echo "this_sha=$THIS_SHA" >> $GITHUB_OUTPUT
+        echo "last_sha=$LAST_SHA" >> $GITHUB_OUTPUT
+
+    - name: check for changes in core/dbt/cli
+      id: check_cli
+      run: |
+        CLI_DIR_CHANGES=$(git diff \
+          ${{ steps.set_shas.outputs.last_sha }} \
+          ${{ steps.set_shas.outputs.this_sha }} \
+          -- ${{ env.CLI_DIR }})
+
+        if [ -n "$CLI_DIR_CHANGES" ]; then
+          echo "changes found"
+          echo $CLI_DIR_CHANGES
+          echo "cli_dir_changed=true" >> $GITHUB_OUTPUT
+          exit 0
+        fi
+        echo "cli_dir_changed=false" >> $GITHUB_OUTPUT
+        echo "no changes found"
+
+    - name: check for changes in core/dbt/docs
+      id: check_docs
+      if: steps.check_cli.outputs.cli_dir_changed == 'false'
+      run: |
+        DOCS_DIR_CHANGES=$(git diff --name-only \
+          ${{ steps.set_shas.outputs.last_sha }} \
+          ${{ steps.set_shas.outputs.this_sha }} \
+          -- ${{ env.DOCS_DIR }} ':!${{ env.DOCS_BUILD_DIR }}')
+
+        DOCS_BUILD_DIR_CHANGES=$(git diff --name-only \
+          ${{ steps.set_shas.outputs.last_sha }} \
+          ${{ steps.set_shas.outputs.this_sha }} \
+          -- ${{ env.DOCS_BUILD_DIR }})
+
+        if [ -n "$DOCS_DIR_CHANGES" ] && [ -z "$DOCS_BUILD_DIR_CHANGES" ]; then
+          echo "changes found"
+          echo $DOCS_DIR_CHANGES
+          echo "docs_dir_changed=true" >> $GITHUB_OUTPUT
+          exit 0
+        fi
+        echo "docs_dir_changed=false" >> $GITHUB_OUTPUT
+        echo "no changes found"
+
+  gen_docs:
+    name: generate docs
+    runs-on: ubuntu-latest
+    needs: [check_gen]
+    if: |
+      needs.check_gen.outputs.cli_dir_changed == 'true'
+      || needs.check_gen.outputs.docs_dir_changed == 'true'
+
+    steps:
+      - name: "[DEBUG] print variables"
+        run: |
+          echo "env.DOCS_DIR:    ${{ env.DOCS_DIR }}"
+          echo "github head_ref: ${{ github.head_ref }}"
+
+      - name: git checkout
+        uses: actions/checkout@v3
+        with:
+          ref: ${{ github.head_ref }}
+
+      - name: install python
+        uses: actions/setup-python@v4.3.0
+        with:
+          python-version: 3.8
+
+      - name: install dev requirements
+        run: |
+          python3 -m venv env
+          source env/bin/activate
+          python -m pip install --upgrade pip
+          pip install -r requirements.txt -r dev-requirements.txt
+
+      - name: generate docs
+        run: |
+          source env/bin/activate
+          cd ${{ env.DOCS_DIR }}
+
+          echo "cleaning existing docs"
+          make clean
+
+          echo "creating docs"
+          make html
+
+      - name: debug
+        run: |
+          echo ">>>>> status"
+          git status
+          echo ">>>>> remotes"
+          git remote -v
+          echo ">>>>> branch"
+          git branch -v
+          echo ">>>>> log"
+          git log --pretty=oneline | head -5
+
+      - name: commit docs
+        run: |
+          git config user.name 'Github Build Bot'
+          git config user.email 'buildbot@fishtownanalytics.com'
+          git commit -am "Add generated CLI API docs"
+          git push -u origin ${{ github.head_ref }}

.github/workflows/jira-creation.yml

@@ -0,0 +1,26 @@
+# **what?**
+# Mirrors issues into Jira. Includes the information: title,
+# GitHub Issue ID and URL
+
+# **why?**
+# Jira is our tool for tracking and we need to see these issues in there
+
+# **when?**
+# On issue creation or when an issue is labeled `Jira`
+
+name: Jira Issue Creation
+
+on:
+  issues:
+    types: [opened, labeled]
+
+permissions:
+  issues: write
+
+jobs:
+  call-label-action:
+    uses: dbt-labs/jira-actions/.github/workflows/jira-creation.yml@main
+    secrets:
+      JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
+      JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
+      JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}

.github/workflows/jira-label.yml

@@ -0,0 +1,26 @@
+# **what?**
+# Calls mirroring Jira label Action. Includes adding a new label
+# to an existing issue or removing a label as well
+
+# **why?**
+# Jira is our tool for tracking and we need to see these labels in there
+
+# **when?**
+# On labels being added or removed from issues
+
+name: Jira Label Mirroring
+
+on:
+  issues:
+    types: [labeled, unlabeled]
+
+permissions:
+  issues: read
+
+jobs:
+  call-label-action:
+    uses: dbt-labs/jira-actions/.github/workflows/jira-label.yml@main
+    secrets:
+      JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
+      JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
+      JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}

.github/workflows/jira-transition.yml

@@ -0,0 +1,27 @@
+# **what?**
+# Transition a Jira issue to a new state
+# Only supports these GitHub Issue transitions:
+#   closed, deleted, reopened
+
+# **why?**
+# Jira needs to be kept up-to-date
+
+# **when?**
+# On issue closing, deletion, reopened
+
+name: Jira Issue Transition
+
+on:
+  issues:
+    types: [closed, deleted, reopened]
+
+# no special access is needed
+permissions: read-all
+
+jobs:
+  call-label-action:
+    uses: dbt-labs/jira-actions/.github/workflows/jira-transition.yml@main
+    secrets:
+      JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
+      JIRA_USER_EMAIL: ${{ secrets.JIRA_USER_EMAIL }}
+      JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}

.github/workflows/main.yml

@@ -0,0 +1,238 @@
+# **what?**
+# Runs code quality checks, unit tests, integration tests and
+# verifies python build on all code commited to the repository. This workflow
+# should not require any secrets since it runs for PRs from forked repos. By
+# default, secrets are not passed to workflows running from a forked repos.
+
+# **why?**
+# Ensure code for dbt meets a certain quality standard.
+
+# **when?**
+# This will run for all PRs, when code is pushed to a release
+# branch, and when manually triggered.
+
+name: Tests and Code Checks
+
+on:
+  push:
+    branches:
+      - "main"
+      - "*.latest"
+      - "releases/*"
+  pull_request:
+  workflow_dispatch:
+
+permissions: read-all
+
+# will cancel previous workflows triggered by the same event and for the same ref for PRs or same SHA otherwise
+concurrency:
+  group: ${{ github.workflow }}-${{ github.event_name }}-${{ contains(github.event_name, 'pull_request') && github.event.pull_request.head.ref || github.sha }}
+  cancel-in-progress: true
+
+defaults:
+  run:
+    shell: bash
+
+jobs:
+  code-quality:
+    name: code-quality
+
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v2
+
+      - name: Set up Python
+        uses: actions/setup-python@v4.3.0
+        with:
+          python-version: '3.8'
+
+      - name: Install python dependencies
+        run: |
+          python -m pip install --user --upgrade pip
+          python -m pip --version
+          python -m pip install pre-commit
+          pre-commit --version
+          python -m pip install mypy==0.942
+          mypy --version
+          python -m pip install -r requirements.txt
+          python -m pip install -r dev-requirements.txt
+          dbt --version
+
+      - name: Run pre-commit hooks
+        run: pre-commit run --all-files --show-diff-on-failure
+
+  unit:
+    name: unit test / python ${{ matrix.python-version }}
+
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.7", "3.8", "3.9", "3.10", "3.11"]
+
+    env:
+      TOXENV: "unit"
+      PYTEST_ADDOPTS: "-v --color=yes --csv unit_results.csv"
+
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v2
+
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: actions/setup-python@v4.3.0
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install python dependencies
+        run: |
+          python -m pip install --user --upgrade pip
+          python -m pip --version
+          python -m pip install tox
+          tox --version
+
+      - name: Run tox
+        run: tox
+
+      - name: Get current date
+        if: always()
+        id: date
+        run: |
+          CURRENT_DATE=$(date +'%Y-%m-%dT%H_%M_%S') # no colons allowed for artifacts
+          echo "date=$CURRENT_DATE" >> $GITHUB_OUTPUT
+
+      - uses: actions/upload-artifact@v2
+        if: always()
+        with:
+          name: unit_results_${{ matrix.python-version }}-${{ steps.date.outputs.date }}.csv
+          path: unit_results.csv
+
+  integration:
+    name: integration test / python ${{ matrix.python-version }} / ${{ matrix.os }}
+
+    runs-on: ${{ matrix.os }}
+    timeout-minutes: 45
+
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ["3.7", "3.8", "3.9", "3.10", "3.11"]
+        os: [ubuntu-20.04]
+        include:
+          - python-version: 3.8
+            os: windows-latest
+          - python-version: 3.8
+            os: macos-latest
+
+    env:
+      TOXENV: integration
+      PYTEST_ADDOPTS: "-v --color=yes -n4 --csv integration_results.csv"
+      DBT_INVOCATION_ENV: github-actions
+      DBT_TEST_USER_1: dbt_test_user_1
+      DBT_TEST_USER_2: dbt_test_user_2
+      DBT_TEST_USER_3: dbt_test_user_3
+
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v2
+
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: actions/setup-python@v4.3.0
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Set up postgres (linux)
+        if: runner.os == 'Linux'
+        uses: ./.github/actions/setup-postgres-linux
+
+      - name: Set up postgres (macos)
+        if: runner.os == 'macOS'
+        uses: ./.github/actions/setup-postgres-macos
+
+      - name: Set up postgres (windows)
+        if: runner.os == 'Windows'
+        uses: ./.github/actions/setup-postgres-windows
+
+      - name: Install python tools
+        run: |
+          python -m pip install --user --upgrade pip
+          python -m pip --version
+          python -m pip install tox
+          tox --version
+
+      - name: Run tests
+        run: tox
+
+      - name: Get current date
+        if: always()
+        id: date
+        run: |
+          CURRENT_DATE=$(date +'%Y-%m-%dT%H_%M_%S') # no colons allowed for artifacts
+          echo "date=$CURRENT_DATE" >> $GITHUB_OUTPUT
+
+      - uses: actions/upload-artifact@v2
+        if: always()
+        with:
+          name: logs_${{ matrix.python-version }}_${{ matrix.os }}_${{ steps.date.outputs.date }}
+          path: ./logs
+
+      - uses: actions/upload-artifact@v2
+        if: always()
+        with:
+          name: integration_results_${{ matrix.python-version }}_${{ matrix.os }}_${{ steps.date.outputs.date }}.csv
+          path: integration_results.csv
+
+  build:
+    name: build packages
+
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out the repository
+        uses: actions/checkout@v2
+
+      - name: Set up Python
+        uses: actions/setup-python@v4.3.0
+        with:
+          python-version: '3.8'
+
+      - name: Install python dependencies
+        run: |
+          python -m pip install --user --upgrade pip
+          python -m pip install --upgrade setuptools wheel twine check-wheel-contents
+          python -m pip --version
+
+      - name: Build distributions
+        run: ./scripts/build-dist.sh
+
+      - name: Show distributions
+        run: ls -lh dist/
+
+      - name: Check distribution descriptions
+        run: |
+          twine check dist/*
+
+      - name: Check wheel contents
+        run: |
+          check-wheel-contents dist/*.whl --ignore W007,W008
+
+      - name: Install wheel distributions
+        run: |
+          find ./dist/*.whl -maxdepth 1 -type f | xargs python -m pip install --force-reinstall --find-links=dist/
+
+      - name: Check wheel distributions
+        run: |
+          dbt --version
+
+      - name: Install source distributions
+        # ignore dbt-1.0.0, which intentionally raises an error when installed from source
+        run: |
+          find ./dist/dbt-[a-z]*.gz -maxdepth 1 -type f | xargs python -m pip install --force-reinstall --find-links=dist/
+
+      - name: Check source distributions
+        run: |
+          dbt --version

.github/workflows/nightly-release.yml

@@ -0,0 +1,109 @@
+# **what?**
+# Nightly releases to GitHub and PyPI. This workflow produces the following outcome:
+# - generate and validate data for night release (commit SHA, version number, release branch);
+# - pass data to release workflow;
+# - night release will be pushed to GitHub as a draft release;
+# - night build will be pushed to test PyPI;
+#
+# **why?**
+# Ensure an automated and tested release process for nightly builds
+#
+# **when?**
+# This workflow runs on schedule or can be run manually on demand.
+
+name: Nightly Test Release to GitHub and PyPI
+
+on:
+  workflow_dispatch: # for manual triggering
+  schedule:
+    - cron: 0 9 * * *
+
+permissions:
+  contents: write # this is the permission that allows creating a new release
+
+defaults:
+  run:
+    shell: bash
+
+env:
+  RELEASE_BRANCH: "main"
+
+jobs:
+  aggregate-release-data:
+    runs-on: ubuntu-latest
+
+    outputs:
+      commit_sha: ${{ steps.resolve-commit-sha.outputs.release_commit }}
+      version_number: ${{ steps.nightly-release-version.outputs.number }}
+      release_branch: ${{ steps.release-branch.outputs.name }}
+
+    steps:
+      - name: "Checkout ${{ github.repository }} Branch ${{ env.RELEASE_BRANCH }}"
+        uses: actions/checkout@v3
+        with:
+          ref: ${{ env.RELEASE_BRANCH }}
+
+      - name: "Resolve Commit To Release"
+        id: resolve-commit-sha
+        run: |
+          commit_sha=$(git rev-parse HEAD)
+          echo "release_commit=$commit_sha" >> $GITHUB_OUTPUT
+
+      - name: "Get Current Version Number"
+        id: version-number-sources
+        run: |
+          current_version=`awk -F"current_version = " '{print $2}' .bumpversion.cfg | tr '\n' ' '`
+          echo "current_version=$current_version" >> $GITHUB_OUTPUT
+
+      - name: "Audit Version And Parse Into Parts"
+        id: semver
+        uses: dbt-labs/actions/parse-semver@v1.1.0
+        with:
+          version: ${{ steps.version-number-sources.outputs.current_version }}
+
+      - name: "Get Current Date"
+        id: current-date
+        run: echo "date=$(date +'%m%d%Y')" >> $GITHUB_OUTPUT
+
+      - name: "Generate Nightly Release Version Number"
+        id: nightly-release-version
+        run: |
+          number="${{ steps.semver.outputs.version }}.dev${{ steps.current-date.outputs.date }}+nightly"
+          echo "number=$number" >> $GITHUB_OUTPUT
+
+      - name: "Audit Nightly Release Version And Parse Into Parts"
+        uses: dbt-labs/actions/parse-semver@v1.1.0
+        with:
+          version: ${{ steps.nightly-release-version.outputs.number }}
+
+      - name: "Set Release Branch"
+        id: release-branch
+        run: |
+          echo "name=${{ env.RELEASE_BRANCH }}" >> $GITHUB_OUTPUT
+
+  log-outputs-aggregate-release-data:
+    runs-on: ubuntu-latest
+    needs: [aggregate-release-data]
+
+    steps:
+      - name: "[DEBUG] Log Outputs"
+        run: |
+          echo commit_sha    : ${{ needs.aggregate-release-data.outputs.commit_sha }}
+          echo version_number: ${{ needs.aggregate-release-data.outputs.version_number }}
+          echo release_branch: ${{ needs.aggregate-release-data.outputs.release_branch }}
+
+  release-github-pypi:
+    needs: [aggregate-release-data]
+
+    uses: ./.github/workflows/release.yml
+    with:
+      sha: ${{ needs.aggregate-release-data.outputs.commit_sha }}
+      target_branch: ${{ needs.aggregate-release-data.outputs.release-branch }}
+      version_number: ${{ needs.aggregate-release-data.outputs.version_number }}
+      build_script_path: "scripts/build-dist.sh"
+      env_setup_script_path: "scripts/env-setup.sh"
+      s3_bucket_name: "core-team-artifacts"
+      package_test_command: "dbt --version"
+      test_run: true
+      nightly_release: true
+    secrets: inherit

.github/workflows/release-branch-tests.yml

@@ -0,0 +1,90 @@
+# **what?**
+# The purpose of this workflow is to trigger CI to run for each
+# release branch and main branch on a regular cadence. If the CI workflow
+# fails for a branch, it will post to dev-core-alerts to raise awareness.
+# The 'aurelien-baudet/workflow-dispatch' Action triggers the existing
+# CI worklow file on the given branch to run so that even if we change the
+# CI workflow file in the future, the one that is tailored for the given
+# release branch will be used.
+
+# **why?**
+# Ensures release branches and main are always shippable and not broken.
+# Also, can catch any dependencies shifting beneath us that might
+# introduce breaking changes (could also impact Cloud).
+
+# **when?**
+# Mainly on a schedule of 9:00, 13:00, 18:00 UTC everyday.
+# Manual trigger can also test on demand
+
+name: Release branch scheduled testing
+
+on:
+  schedule:
+    - cron: '0 9,13,18 * * *' # 9:00, 13:00, 18:00 UTC
+
+  workflow_dispatch: # for manual triggering
+
+# no special access is needed
+permissions: read-all
+
+jobs:
+  fetch-latest-branches:
+    runs-on: ubuntu-latest
+
+    outputs:
+      latest-branches: ${{ steps.get-latest-branches.outputs.repo-branches }}
+
+    steps:
+      - name: "Fetch dbt-core Latest Branches"
+        uses: dbt-labs/actions/fetch-repo-branches@v1.1.1
+        id: get-latest-branches
+        with:
+          repo_name: ${{ github.event.repository.name }}
+          organization: "dbt-labs"
+          pat: ${{ secrets.GITHUB_TOKEN }}
+          fetch_protected_branches_only: true
+          regex: "^1.[0-9]+.latest$"
+          perform_match_method: "match"
+          retries: 3
+
+      - name: "[ANNOTATION] ${{ github.event.repository.name }} - branches to test"
+        run: |
+          title="${{ github.event.repository.name }} - branches to test"
+          message="The workflow will run tests for the following branches of the ${{ github.event.repository.name }} repo: ${{ steps.get-latest-branches.outputs.repo-branches }}"
+          echo "::notice $title::$message"
+
+  kick-off-ci:
+    needs: [fetch-latest-branches]
+    name: Kick-off CI
+    runs-on: ubuntu-latest
+
+    strategy:
+      # must run CI 1 branch at a time b/c the workflow-dispatch Action polls for
+      # latest run for results and it gets confused when we kick off multiple runs
+      # at once. There is a race condition so we will just run in sequential order.
+      max-parallel: 1
+      fail-fast: false
+      matrix:
+        branch: ${{ fromJSON(needs.fetch-latest-branches.outputs.latest-branches) }}
+        include:
+          - branch: 'main'
+
+    steps:
+    - name: Call CI workflow for ${{ matrix.branch }} branch
+      id: trigger-step
+      uses: aurelien-baudet/workflow-dispatch@v2.1.1
+      with:
+        workflow: main.yml
+        ref: ${{ matrix.branch }}
+        token: ${{ secrets.FISHTOWN_BOT_PAT }}
+
+    - name: Post failure to Slack
+      uses: ravsamhq/notify-slack-action@v1
+      if: ${{ always() && !contains(steps.trigger-step.outputs.workflow-conclusion,'success') }}
+      with:
+        status: ${{ job.status }}
+        notification_title: 'dbt-core scheduled run of "${{ matrix.branch }}" branch not successful'
+        message_format: ':x: CI on branch "${{ matrix.branch }}" ${{ steps.trigger-step.outputs.workflow-conclusion }}'
+        footer: 'Linked failed CI run ${{ steps.trigger-step.outputs.workflow-url }}'
+      env:
+        SLACK_WEBHOOK_URL: ${{ secrets.SLACK_DEV_CORE_ALERTS }}

.github/workflows/release-docker.yml

@@ -0,0 +1,118 @@
+# **what?**
+# This workflow will generate a series of docker images for dbt and push them to the github container registry
+
+# **why?**
+# Docker images for dbt are used in a number of important places throughout the dbt ecosystem.  This is how we keep those images up-to-date.
+
+# **when?**
+# This is triggered manually
+
+# **next steps**
+# - build this into the release workflow (or conversly, break out the different release methods into their own workflow files)
+
+name: Docker release
+
+permissions:
+  packages: write
+
+on:
+  workflow_dispatch:
+    inputs:
+      package:
+       description: The package to release. _One_ of [dbt-core, dbt-redshift, dbt-bigquery, dbt-snowflake, dbt-spark, dbt-postgres]
+       required: true
+      version_number:
+       description: The release version number (i.e. 1.0.0b1). Do not include `latest` tags or a leading `v`!
+       required: true
+
+jobs:
+  get_version_meta:
+    name: Get version meta
+    runs-on: ubuntu-latest
+    outputs:
+      major: ${{ steps.version.outputs.major }}
+      minor: ${{ steps.version.outputs.minor }}
+      patch: ${{ steps.version.outputs.patch }}
+      latest: ${{ steps.latest.outputs.latest }}
+      minor_latest: ${{ steps.latest.outputs.minor_latest }}
+    steps:
+      - uses: actions/checkout@v1
+      - name: Split version
+        id: version
+        run: |
+          IFS="." read -r MAJOR MINOR PATCH <<< ${{ github.event.inputs.version_number }}
+          echo "major=$MAJOR" >> $GITHUB_OUTPUT
+          echo "minor=$MINOR" >> $GITHUB_OUTPUT
+          echo "patch=$PATCH" >> $GITHUB_OUTPUT
+
+      - name: Is pkg 'latest'
+        id: latest
+        uses: ./.github/actions/latest-wrangler
+        with:
+          package: ${{ github.event.inputs.package }}
+          new_version: ${{ github.event.inputs.version_number }}
+          gh_token: ${{ secrets.GITHUB_TOKEN }}
+          halt_on_missing: False
+
+  setup_image_builder:
+    name: Set up docker image builder
+    runs-on: ubuntu-latest
+    needs: [get_version_meta]
+    steps:
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v1
+
+  build_and_push:
+    name: Build images and push to GHCR
+    runs-on: ubuntu-latest
+    needs: [setup_image_builder, get_version_meta]
+    steps:
+      - name: Get docker build arg
+        id: build_arg
+        run: |
+          BUILD_ARG_NAME=$(echo ${{ github.event.inputs.package }} | sed 's/\-/_/g')
+          BUILD_ARG_VALUE=$(echo ${{ github.event.inputs.package }} | sed 's/postgres/core/g')
+          echo "build_arg_name=$BUILD_ARG_NAME" >> $GITHUB_OUTPUT
+          echo "build_arg_value=$BUILD_ARG_VALUE" >> $GITHUB_OUTPUT
+
+      - name: Log in to the GHCR
+        uses: docker/login-action@v1
+        with:
+          registry: ghcr.io
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Build and push MAJOR.MINOR.PATCH tag
+        uses: docker/build-push-action@v2
+        with:
+          file: docker/Dockerfile
+          push: True
+          target: ${{ github.event.inputs.package }}
+          build-args: |
+            ${{ steps.build_arg.outputs.build_arg_name }}_ref=${{ steps.build_arg.outputs.build_arg_value }}@v${{ github.event.inputs.version_number }}
+          tags: |
+            ghcr.io/dbt-labs/${{ github.event.inputs.package }}:${{ github.event.inputs.version_number }}
+
+      - name: Build and push MINOR.latest tag
+        uses: docker/build-push-action@v2
+        if: ${{ needs.get_version_meta.outputs.minor_latest == 'True' }}
+        with:
+          file: docker/Dockerfile
+          push: True
+          target: ${{ github.event.inputs.package }}
+          build-args: |
+            ${{ steps.build_arg.outputs.build_arg_name }}_ref=${{ steps.build_arg.outputs.build_arg_value }}@v${{ github.event.inputs.version_number }}
+          tags: |
+            ghcr.io/dbt-labs/${{ github.event.inputs.package }}:${{ needs.get_version_meta.outputs.major }}.${{ needs.get_version_meta.outputs.minor }}.latest
+
+      - name: Build and push latest tag
+        uses: docker/build-push-action@v2
+        if: ${{ needs.get_version_meta.outputs.latest == 'True' }}
+        with:
+          file: docker/Dockerfile
+          push: True
+          target: ${{ github.event.inputs.package }}
+          build-args: |
+            ${{ steps.build_arg.outputs.build_arg_name }}_ref=${{ steps.build_arg.outputs.build_arg_value }}@v${{ github.event.inputs.version_number }}
+          tags: |
+            ghcr.io/dbt-labs/${{ github.event.inputs.package }}:latest

.github/workflows/release.yml

@@ -0,0 +1,230 @@
+# **what?**
+# Release workflow provides the following steps:
+# - checkout the given commit;
+# - validate version in sources and changelog file for given version;
+# - bump the version and generate a changelog if needed;
+# - merge all changes to the target branch if needed;
+# - run unit and integration tests against given commit;
+# - build and package that SHA;
+# - release it to GitHub and PyPI with that specific build;
+#
+# **why?**
+# Ensure an automated and tested release process
+#
+# **when?**
+# This workflow can be run manually on demand or can be called by other workflows
+
+name: Release to GitHub and PyPI
+
+on:
+  workflow_dispatch:
+    inputs:
+      sha:
+        description: "The last commit sha in the release"
+        type: string
+        required: true
+      target_branch:
+        description: "The branch to release from"
+        type: string
+        required: true
+      version_number:
+        description: "The release version number (i.e. 1.0.0b1)"
+        type: string
+        required: true
+      build_script_path:
+        description: "Build script path"
+        type: string
+        default: "scripts/build-dist.sh"
+        required: true
+      env_setup_script_path:
+        description: "Environment setup script path"
+        type: string
+        default: "scripts/env-setup.sh"
+        required: false
+      s3_bucket_name:
+        description: "AWS S3 bucket name"
+        type: string
+        default: "core-team-artifacts"
+        required: true
+      package_test_command:
+        description: "Package test command"
+        type: string
+        default: "dbt --version"
+        required: true
+      test_run:
+        description: "Test run (Publish release as draft)"
+        type: boolean
+        default: true
+        required: false
+      nightly_release:
+        description: "Nightly release to dev environment"
+        type: boolean
+        default: false
+        required: false
+  workflow_call:
+    inputs:
+      sha:
+        description: "The last commit sha in the release"
+        type: string
+        required: true
+      target_branch:
+        description: "The branch to release from"
+        type: string
+        required: true
+      version_number:
+        description: "The release version number (i.e. 1.0.0b1)"
+        type: string
+        required: true
+      build_script_path:
+        description: "Build script path"
+        type: string
+        default: "scripts/build-dist.sh"
+        required: true
+      env_setup_script_path:
+        description: "Environment setup script path"
+        type: string
+        default: "scripts/env-setup.sh"
+        required: false
+      s3_bucket_name:
+        description: "AWS S3 bucket name"
+        type: string
+        default: "core-team-artifacts"
+        required: true
+      package_test_command:
+        description: "Package test command"
+        type: string
+        default: "dbt --version"
+        required: true
+      test_run:
+        description: "Test run (Publish release as draft)"
+        type: boolean
+        default: true
+        required: false
+      nightly_release:
+        description: "Nightly release to dev environment"
+        type: boolean
+        default: false
+        required: false
+
+permissions:
+  contents: write # this is the permission that allows creating a new release
+
+defaults:
+  run:
+    shell: bash
+
+jobs:
+  log-inputs:
+    name: Log Inputs
+    runs-on: ubuntu-latest
+    steps:
+      - name: "[DEBUG] Print Variables"
+        run: |
+          echo The last commit sha in the release: ${{ inputs.sha }}
+          echo The branch to release from:         ${{ inputs.target_branch }}
+          echo The release version number:         ${{ inputs.version_number }}
+          echo Build script path:                  ${{ inputs.build_script_path }}
+          echo Environment setup script path:      ${{ inputs.env_setup_script_path }}
+          echo AWS S3 bucket name:                 ${{ inputs.s3_bucket_name }}
+          echo Package test command:               ${{ inputs.package_test_command }}
+          echo Test run:                           ${{ inputs.test_run }}
+          echo Nightly release:                    ${{ inputs.nightly_release }}
+
+  bump-version-generate-changelog:
+    name: Bump package version, Generate changelog
+
+    uses: dbt-labs/dbt-release/.github/workflows/release-prep.yml@main
+
+    with:
+      sha: ${{ inputs.sha }}
+      version_number: ${{ inputs.version_number }}
+      target_branch: ${{ inputs.target_branch }}
+      env_setup_script_path: ${{ inputs.env_setup_script_path }}
+      test_run: ${{ inputs.test_run }}
+      nightly_release: ${{ inputs.nightly_release }}
+
+    secrets:
+      FISHTOWN_BOT_PAT: ${{ secrets.FISHTOWN_BOT_PAT }}
+
+  log-outputs-bump-version-generate-changelog:
+    name: "[Log output] Bump package version, Generate changelog"
+    if: ${{ !failure() && !cancelled() }}
+
+    needs: [bump-version-generate-changelog]
+
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Print variables
+        run: |
+          echo Final SHA     : ${{ needs.bump-version-generate-changelog.outputs.final_sha }}
+          echo Changelog path: ${{ needs.bump-version-generate-changelog.outputs.changelog_path }}
+
+  build-test-package:
+    name: Build, Test, Package
+    if: ${{ !failure() && !cancelled() }}
+    needs: [bump-version-generate-changelog]
+
+    uses: dbt-labs/dbt-release/.github/workflows/build.yml@main
+
+    with:
+      sha: ${{ needs.bump-version-generate-changelog.outputs.final_sha }}
+      version_number: ${{ inputs.version_number }}
+      changelog_path: ${{ needs.bump-version-generate-changelog.outputs.changelog_path }}
+      build_script_path: ${{ inputs.build_script_path }}
+      s3_bucket_name: ${{ inputs.s3_bucket_name }}
+      package_test_command: ${{ inputs.package_test_command }}
+      test_run: ${{ inputs.test_run }}
+      nightly_release: ${{ inputs.nightly_release }}
+
+    secrets:
+      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
+      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+
+  github-release:
+    name: GitHub Release
+    if: ${{ !failure() && !cancelled() }}
+
+    needs: [bump-version-generate-changelog, build-test-package]
+
+    uses: dbt-labs/dbt-release/.github/workflows/github-release.yml@main
+
+    with:
+      sha: ${{ needs.bump-version-generate-changelog.outputs.final_sha }}
+      version_number: ${{ inputs.version_number }}
+      changelog_path: ${{ needs.bump-version-generate-changelog.outputs.changelog_path }}
+      test_run: ${{ inputs.test_run }}
+
+  pypi-release:
+    name: PyPI Release
+
+    needs: [github-release]
+
+    uses: dbt-labs/dbt-release/.github/workflows/pypi-release.yml@main
+
+    with:
+      version_number: ${{ inputs.version_number }}
+      test_run: ${{ inputs.test_run }}
+
+    secrets:
+      PYPI_API_TOKEN: ${{ secrets.PYPI_API_TOKEN }}
+      TEST_PYPI_API_TOKEN: ${{ secrets.TEST_PYPI_API_TOKEN }}
+
+  slack-notification:
+    name: Slack Notification
+    if: ${{ failure() && (!inputs.test_run || inputs.nightly_release) }}
+
+    needs:
+      [
+        bump-version-generate-changelog,
+        build-test-package,
+        github-release,
+        pypi-release,
+      ]
+
+    uses: dbt-labs/dbt-release/.github/workflows/slack-post-notification.yml@main
+    with:
+      status: "failure"
+
+    secrets:
+      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_DEV_CORE_ALERTS }}

.github/workflows/schema-check.yml

@@ -0,0 +1,90 @@
+# **what?**
+# Compares the schema of the dbt version of the given ref vs
+# the latest official schema releases found in schemas.getdbt.com.
+# If there are differences, the workflow will fail and upload the
+# diff as an artifact. The metadata team should be alerted to the change.
+#
+# **why?**
+# Reaction work may need to be done if artifact schema changes
+# occur so we want to proactively alert to it.
+#
+# **when?**
+# On pushes to `develop` and release branches. Manual runs are also enabled.
+name: Artifact Schema Check
+
+on:
+  workflow_dispatch:
+  pull_request: #TODO: remove before merging
+  push:
+    branches:
+      - "develop"
+      - "*.latest"
+      - "releases/*"
+
+# no special access is needed
+permissions: read-all
+
+env:
+  LATEST_SCHEMA_PATH: ${{ github.workspace }}/new_schemas
+  SCHEMA_DIFF_ARTIFACT: ${{ github.workspace }}//schema_schanges.txt
+  DBT_REPO_DIRECTORY: ${{ github.workspace }}/dbt
+  SCHEMA_REPO_DIRECTORY: ${{ github.workspace }}/schemas.getdbt.com
+
+jobs:
+  checking-schemas:
+    name: "Checking schemas"
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Set up Python
+        uses: actions/setup-python@v2
+        with:
+          python-version: 3.8
+
+      - name: Checkout dbt repo
+        uses: actions/checkout@v2.3.4
+        with:
+            path: ${{ env.DBT_REPO_DIRECTORY }}
+
+      - name: Checkout schemas.getdbt.com repo
+        uses: actions/checkout@v2.3.4
+        with:
+          repository: dbt-labs/schemas.getdbt.com
+          ref: 'main'
+          ssh-key: ${{ secrets.SCHEMA_SSH_PRIVATE_KEY }}
+          path: ${{ env.SCHEMA_REPO_DIRECTORY }}
+
+      - name: Generate current schema
+        run: |
+          cd ${{ env.DBT_REPO_DIRECTORY }}
+          python3 -m venv env
+          source env/bin/activate
+          pip install --upgrade pip
+          pip install -r dev-requirements.txt -r editable-requirements.txt
+          python scripts/collect-artifact-schema.py --path ${{ env.LATEST_SCHEMA_PATH }}
+
+      # Copy generated schema files into the schemas.getdbt.com repo
+      # Do a git diff to find any changes
+      # Ignore any date or version changes though
+      - name: Compare schemas
+        run: |
+          cp -r ${{ env.LATEST_SCHEMA_PATH }}/dbt ${{ env.SCHEMA_REPO_DIRECTORY }}
+          cd ${{ env.SCHEMA_REPO_DIRECTORY }}
+          diff_results=$(git diff -I='*[0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|[1-2][0-9]|3[0-1])T' \
+          -I='*[0-9]{1}.[0-9]{2}.[0-9]{1}(rc[0-9]|b[0-9]| )' --compact-summary)
+          if [[ $(echo diff_results) ]]; then
+            echo $diff_results
+            echo "Schema changes detected!"
+            git diff -I='*[0-9]{4}-(0[1-9]|1[0-2])-(0[1-9]|[1-2][0-9]|3[0-1])T' \
+              -I='*[0-9]{1}.[0-9]{2}.[0-9]{1}(rc[0-9]|b[0-9]| )' > ${{ env.SCHEMA_DIFF_ARTIFACT }}
+            exit 1
+          else
+            echo "No schema changes detected"
+          fi
+
+      - name: Upload schema diff
+        uses: actions/upload-artifact@v2.2.4
+        if: ${{ failure() }}
+        with:
+          name: 'schema_schanges.txt'
+          path: '${{ env.SCHEMA_DIFF_ARTIFACT }}'

.github/workflows/stale.yml

@@ -0,0 +1,12 @@
+name: "Close stale issues and PRs"
+on:
+  schedule:
+    - cron: "30 1 * * *"
+
+permissions:
+  issues: write
+  pull-requests: write
+
+jobs:
+  stale:
+    uses: dbt-labs/actions/.github/workflows/stale-bot-matrix.yml@main

.github/workflows/structured-logging-schema-check.yml

@@ -0,0 +1,65 @@
+# This Action checks makes a dbt run to sample json structured logs
+# and checks that they conform to the currently documented schema.
+#
+# If this action fails it either means we have unintentionally deviated
+# from our documented structured logging schema, or we need to bump the
+# version of our structured logging and add new documentation to
+# communicate these changes.
+
+name: Structured Logging Schema Check
+on:
+  push:
+    branches:
+      - "main"
+      - "*.latest"
+      - "releases/*"
+  pull_request:
+  workflow_dispatch:
+
+permissions: read-all
+
+jobs:
+  # run the performance measurements on the current or default branch
+  test-schema:
+    name: Test Log Schema
+    runs-on: ubuntu-20.04
+    env:
+      # turns warnings into errors
+      RUSTFLAGS: "-D warnings"
+      # points tests to the log file
+      LOG_DIR: "/home/runner/work/dbt-core/dbt-core/logs"
+      # tells integration tests to output into json format
+      DBT_LOG_FORMAT: "json"
+      # Additional test users
+      DBT_TEST_USER_1: dbt_test_user_1
+      DBT_TEST_USER_2: dbt_test_user_2
+      DBT_TEST_USER_3: dbt_test_user_3
+
+    steps:
+      - name: checkout dev
+        uses: actions/checkout@v2
+        with:
+          persist-credentials: false
+
+      - name: Setup Python
+        uses: actions/setup-python@v2.2.2
+        with:
+          python-version: "3.8"
+
+      - name: Install python dependencies
+        run: |
+          pip install --user --upgrade pip
+          pip --version
+          pip install tox
+          tox --version
+
+      - name: Set up postgres
+        uses: ./.github/actions/setup-postgres-linux
+
+      - name: ls
+        run: ls
+
+      # integration tests generate a ton of logs in different files. the next step will find them all.
+      # we actually care if these pass, because the normal test run doesn't usually include many json log outputs
+      - name: Run integration tests
+        run: tox -e integration -- -nauto

.github/workflows/test/.actrc

@@ -0,0 +1 @@
+-P ubuntu-latest=ghcr.io/catthehacker/ubuntu:act-latest

.github/workflows/test/.gitignore

@@ -0,0 +1 @@
+.secrets

.github/workflows/test/.secrets.EXAMPLE

@@ -0,0 +1 @@
+GITHUB_TOKEN=GH_PERSONAL_ACCESS_TOKEN_GOES_HERE

.github/workflows/test/inputs/release_docker.json

@@ -0,0 +1,6 @@
+{
+    "inputs": {
+      "version_number": "1.0.1",
+      "package": "dbt-postgres"
+    }
+}

.github/workflows/triage-labels.yml

@@ -0,0 +1,33 @@
+# **what?**
+# When the core team triages, we sometimes need more information from the issue creator.  In
+# those cases we remove the `triage` label and add the `awaiting_response` label.  Once we
+# recieve a response in the form of a comment, we want the `awaiting_response` label removed
+# in favor of the `triage` label so we are aware that the issue needs action.
+
+# **why?**
+# To help with out team triage issue tracking
+
+# **when?**
+# This will run when a comment is added to an issue and that issue has to `awaiting_response` label.
+
+name: Update Triage Label
+
+on: issue_comment
+
+defaults:
+  run:
+    shell: bash
+
+permissions:
+  issues: write
+
+jobs:
+  triage_label:
+    if: contains(github.event.issue.labels.*.name, 'awaiting_response')
+    runs-on: ubuntu-latest
+    steps:
+      - name: initial labeling
+        uses: andymckay/labeler@master
+        with:
+          add-labels: "triage"
+          remove-labels: "awaiting_response"

.github/workflows/version-bump.yml

@@ -0,0 +1,125 @@
+# **what?**
+# This workflow will take the new version number to bump to. With that
+# it will run versionbump to update the version number everywhere in the
+# code base and then run changie to create the corresponding changelog.
+# A PR will be created with the changes that can be reviewed before committing.
+
+# **why?**
+# This is to aid in releasing dbt and making sure we have updated
+# the version in all places and generated the changelog.
+
+# **when?**
+# This is triggered manually
+
+name: Version Bump
+
+on:
+  workflow_dispatch:
+    inputs:
+      version_number:
+       description: 'The version number to bump to (ex. 1.2.0, 1.3.0b1)'
+       required: true
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  bump:
+    runs-on: ubuntu-latest
+    steps:
+      - name: "[DEBUG] Print Variables"
+        run: |
+          echo "all variables defined as inputs"
+          echo The version_number: ${{ github.event.inputs.version_number }}
+
+      - name: Check out the repository
+        uses: actions/checkout@v2
+
+      - uses: actions/setup-python@v2
+        with:
+          python-version: "3.8"
+
+      - name: Install python dependencies
+        run: |
+          python3 -m venv env
+          source env/bin/activate
+          pip install --upgrade pip
+
+      - name: Add Homebrew to PATH
+        run: |
+          echo "/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin" >> $GITHUB_PATH
+
+      - name: Install Homebrew packages
+        run: |
+          brew install pre-commit
+          brew tap miniscruff/changie https://github.com/miniscruff/changie
+          brew install changie
+
+      - name: Audit Version and Parse Into Parts
+        id: semver
+        uses: dbt-labs/actions/parse-semver@v1
+        with:
+          version: ${{ github.event.inputs.version_number }}
+
+      - name: Set branch value
+        id: variables
+        run: |
+          echo "BRANCH_NAME=prep-release/${{ github.event.inputs.version_number }}_$GITHUB_RUN_ID" >> $GITHUB_OUTPUT
+
+      - name: Create PR branch
+        run: |
+          git checkout -b ${{ steps.variables.outputs.BRANCH_NAME }}
+          git push origin ${{ steps.variables.outputs.BRANCH_NAME }}
+          git branch --set-upstream-to=origin/${{ steps.variables.outputs.BRANCH_NAME }} ${{ steps.variables.outputs.BRANCH_NAME }}
+
+      - name: Bump version
+        run: |
+          source env/bin/activate
+          pip install -r dev-requirements.txt
+          env/bin/bumpversion --allow-dirty --new-version ${{ github.event.inputs.version_number }} major
+          git status
+
+      - name: Run changie
+        run: |
+          if [[ ${{ steps.semver.outputs.is-pre-release }} -eq 1 ]]
+          then
+            changie batch ${{ steps.semver.outputs.base-version }}  --move-dir '${{ steps.semver.outputs.base-version }}' --prerelease '${{ steps.semver.outputs.pre-release }}'
+          else
+            changie batch ${{ steps.semver.outputs.base-version }}  --include '${{ steps.semver.outputs.base-version }}' --remove-prereleases
+          fi
+          changie merge
+          git status
+
+      # this step will fail on whitespace errors but also correct them
+      - name: Remove trailing whitespace
+        continue-on-error: true
+        run: |
+          pre-commit run trailing-whitespace --files .bumpversion.cfg CHANGELOG.md .changes/*
+          git status
+
+      # this step will fail on newline errors but also correct them
+      - name: Removing extra newlines
+        continue-on-error: true
+        run: |
+          pre-commit run end-of-file-fixer --files .bumpversion.cfg CHANGELOG.md .changes/*
+          git status
+
+      - name: Commit version bump to branch
+        uses: EndBug/add-and-commit@v7
+        with:
+          author_name: 'Github Build Bot'
+          author_email: 'buildbot@fishtownanalytics.com'
+          message: 'Bumping version to ${{ github.event.inputs.version_number }} and generate CHANGELOG'
+          branch: '${{ steps.variables.outputs.BRANCH_NAME }}'
+          push: 'origin origin/${{ steps.variables.outputs.BRANCH_NAME }}'
+
+      - name: Create Pull Request
+        uses: peter-evans/create-pull-request@v3
+        with:
+          author: 'Github Build Bot <buildbot@fishtownanalytics.com>'
+          base: ${{github.ref}}
+          title: 'Bumping version to ${{ github.event.inputs.version_number }} and generate changelog'
+          branch: '${{ steps.variables.outputs.BRANCH_NAME }}'
+          labels: |
+            Skip Changelog

.gitignore

@@ -8,8 +8,10 @@ __pycache__/
 
 # Distribution / packaging
 .Python
-env/
+env*/
+dbt_env/
 build/
+!core/dbt/docs/build
 develop-eggs/
 dist/
 downloads/
@@ -23,6 +25,8 @@ var/
 *.egg-info/
 .installed.cfg
 *.egg
+.mypy_cache/
+.dmypy.json
 logs/
 
 # PyInstaller
@@ -41,11 +45,15 @@ htmlcov/
 .coverage
 .coverage.*
 .cache
+.env
 nosetests.xml
 coverage.xml
 *,cover
 .hypothesis/
 test.env
+makefile.test.env
+*.pytest_cache/
+
 
 # Translations
 *.mo
@@ -60,8 +68,37 @@ docs/_build/
 # PyBuilder
 target/
 
-#Ipython Notebook
+# Ipython Notebook
 .ipynb_checkpoints
 
-#Emacs
+# Emacs
 *~
+
+# Sublime Text
+*.sublime-*
+
+# Vim
+*.sw*
+
+# Pyenv
+.python-version
+
+# Vim
+*.sw*
+
+# pycharm
+.idea/
+venv/
+
+# AWS credentials
+.aws/
+
+# MacOS
+.DS_Store
+
+# vscode
+.vscode/
+*.code-workspace
+
+# poetry
+poetry.lock

.pre-commit-config.yaml

@@ -0,0 +1,63 @@
+# Configuration for pre-commit hooks (see https://pre-commit.com/).
+# Eventually the hooks described here will be run as tests before merging each PR.
+
+# TODO: remove global exclusion of tests when testing overhaul is complete
+exclude: ^(test/|core/dbt/docs/build/)
+
+# Force all unspecified python hooks to run python 3.8
+default_language_version:
+  python: python3
+
+repos:
+- repo: https://github.com/pre-commit/pre-commit-hooks
+  rev: v3.2.0
+  hooks:
+  - id: check-yaml
+    args: [--unsafe]
+  - id: check-json
+  - id: end-of-file-fixer
+  - id: trailing-whitespace
+    exclude_types:
+      - "markdown"
+  - id: check-case-conflict
+- repo: https://github.com/psf/black
+  rev: 22.3.0
+  hooks:
+  - id: black
+  - id: black
+    alias: black-check
+    stages: [manual]
+    args:
+    - "--check"
+    - "--diff"
+- repo: https://github.com/pycqa/flake8
+  rev: 4.0.1
+  hooks:
+  - id: flake8
+  - id: flake8
+    alias: flake8-check
+    stages: [manual]
+- repo: https://github.com/pre-commit/mirrors-mypy
+  rev: v0.942
+  hooks:
+  - id: mypy
+    # N.B.: Mypy is... a bit fragile.
+    #
+    # By using `language: system` we run this hook in the local
+    # environment instead of a pre-commit isolated one.  This is needed
+    # to ensure mypy correctly parses the project.
+
+    # It may cause trouble
+    # in that it adds environmental variables out of our control to the
+    # mix.  Unfortunately, there's nothing we can do about per pre-commit's
+    # author.
+    # See https://github.com/pre-commit/pre-commit/issues/730 for details.
+    args: [--show-error-codes]
+    files: ^core/dbt/
+    language: system
+  - id: mypy
+    alias: mypy-check
+    stages: [manual]
+    args: [--show-error-codes, --pretty]
+    files: ^core/dbt/
+    language: system

ARCHITECTURE.md

@@ -0,0 +1,54 @@
+The core function of dbt is SQL compilation and execution. Users create projects of dbt resources (models, tests, seeds, snapshots, ...), defined in SQL and YAML files, and they invoke dbt to create, update, or query associated views and tables. Today, dbt makes heavy use of Jinja2 to enable the templating of SQL, and to construct a DAG (Directed Acyclic Graph) from all of the resources in a project. Users can also extend their projects by installing resources (including Jinja macros) from other projects, called "packages."
+
+## dbt-core
+
+Most of the python code in the repository is within the `core/dbt` directory.
+- [`single python files`](core/dbt/README.md): A number of individual files, such as 'compilation.py' and 'exceptions.py'
+
+The main subdirectories of core/dbt:
+- [`adapters`](core/dbt/adapters/README.md): Define base classes for behavior that is likely to differ across databases
+- [`clients`](core/dbt/clients/README.md): Interface with dependencies (agate, jinja) or across operating systems
+- [`config`](core/dbt/config/README.md): Reconcile user-supplied configuration from connection profiles, project files, and Jinja macros
+- [`context`](core/dbt/context/README.md): Build and expose dbt-specific Jinja functionality
+- [`contracts`](core/dbt/contracts/README.md): Define Python objects (dataclasses) that dbt expects to create and validate
+- [`deps`](core/dbt/deps/README.md): Package installation and dependency resolution
+- [`events`](core/dbt/events/README.md): Logging events
+- [`graph`](core/dbt/graph/README.md): Produce a `networkx` DAG of project resources, and selecting those resources given user-supplied criteria
+- [`include`](core/dbt/include/README.md): The dbt "global project," which defines default implementations of Jinja2 macros
+- [`parser`](core/dbt/parser/README.md): Read project files, validate, construct python objects
+- [`task`](core/dbt/task/README.md): Set forth the actions that dbt can perform when invoked
+
+Legacy tests are found in the 'test' directory:
+- [`unit tests`](core/dbt/test/unit/README.md): Unit tests
+- [`integration tests`](core/dbt/test/integration/README.md): Integration tests
+
+### Invoking dbt
+
+The "tasks" map to top-level dbt commands. So `dbt run` => task.run.RunTask, etc. Some are more like abstract base classes (GraphRunnableTask, for example) but all the concrete types outside of task should map to tasks. Currently one executes at a time. The tasks kick off their “Runners” and those do execute in parallel. The parallelism is managed via a thread pool, in GraphRunnableTask.
+
+core/dbt/include/index.html
+This is the docs website code. It comes from the dbt-docs repository, and is generated when a release is packaged.
+
+## Adapters
+
+dbt uses an adapter-plugin pattern to extend support to different databases, warehouses, query engines, etc. For testing and development purposes, the dbt-postgres plugin lives alongside the dbt-core codebase, in the [`plugins`](plugins) subdirectory. Like other adapter plugins, it is a self-contained codebase and package that builds on top of dbt-core.
+
+Each adapter is a mix of python, Jinja2, and SQL. The adapter code also makes heavy use of Jinja2 to wrap modular chunks of SQL functionality, define default implementations, and allow plugins to override it.
+
+Each adapter plugin is a standalone python package that includes:
+
+- `dbt/include/[name]`: A "sub-global" dbt project, of YAML and SQL files, that reimplements Jinja macros to use the adapter's supported SQL syntax
+- `dbt/adapters/[name]`: Python modules that inherit, and optionally reimplement, the base adapter classes defined in dbt-core
+- `setup.py`
+
+The Postgres adapter code is the most central, and many of its implementations are used as the default defined in the dbt-core global project. The greater the distance of a data technology from Postgres, the more its adapter plugin may need to reimplement.
+
+## Testing dbt
+
+The [`test/`](test/) subdirectory includes unit and integration tests that run as continuous integration checks against open pull requests. Unit tests check mock inputs and outputs of specific python functions. Integration tests perform end-to-end dbt invocations against real adapters (Postgres, Redshift, Snowflake, BigQuery) and assert that the results match expectations. See [the contributing guide](CONTRIBUTING.md) for a step-by-step walkthrough of setting up a local development and testing environment.
+
+## Everything else
+
+- [docker](docker/): All dbt versions are published as Docker images on DockerHub. This subfolder contains the `Dockerfile` (constant) and `requirements.txt` (one for each version).
+- [etc](etc/): Images for README
+- [scripts](scripts/): Helper scripts for testing, releasing, and producing JSON schemas. These are not included in distributions of dbt, nor are they rigorously tested—they're just handy tools for the dbt maintainers :)

CHANGELOG.md

@@ -1,944 +1,28 @@
-## dbt 0.7.0 (February 9, 2017)
-
-### Overview
-
-- Snowflake Support
-- Deprecations
-
-### Snowflake Support
-
-dbt now supports [Snowflake](https://www.snowflake.net/) as a target in addition to Postgres and Redshift! All dbt functionality is supported in this new warehouse. There is a sample snowflake profile in [sample.profiles.yml](https://github.com/analyst-collective/dbt/blob/development/sample.profiles.yml) -- you can start using it right away.
-
-### Deprecations
-
-There are a few deprecations in 0.7:
-
- - `run-target` in profiles.yml is no longer supported. Use `target` instead.
- - Project names (`name` in dbt_project.yml) can now only contain letters, numbers, and underscores, and must start with a letter. Previously they could contain any character.
- - `--dry-run` is no longer supported.
-
-### Notes
-
-#### New Features
-
-- dbt now supports [Snowflake](https://www.snowflake.net/) as a warehouse ([#259](https://github.com/analyst-collective/dbt/pull/259))
-
-#### Bugfixes
-
-- use adapter for sort/dist ([#274](https://github.com/analyst-collective/dbt/pull/274))
-
-#### Deprecations
-
-- run-target and name validations ([#280](https://github.com/analyst-collective/dbt/pull/280))
-- dry-run removed ([#281](https://github.com/analyst-collective/dbt/pull/281))
-
-#### Changes
-
-- fixed a typo in the docs related to post-run hooks ([#271](https://github.com/analyst-collective/dbt/pull/271))
-- refactored tracking code to refresh invocation id in a multi-run context ([#273](https://github.com/analyst-collective/dbt/pull/273))
-- added unit tests for the graph ([#270](https://github.com/analyst-collective/dbt/pull/270))
-
-## dbt 0.6.2 (January 16, 2017)
-
-#### Changes
-
-- condense error output when `--debug` is not set ([#265](https://github.com/analyst-collective/dbt/pull/265))
-
-## dbt 0.6.1 (January 11, 2017)
-
-#### Bugfixes
-
-- respect `config` options in profiles.yml ([#255](https://github.com/analyst-collective/dbt/pull/255))
-- use correct `on-run-end` option for post-run hooks ([#261](https://github.com/analyst-collective/dbt/pull/261))
-
-#### Changes
-
-- add `--debug` flag, replace calls to `print()` with a global logger ([#256](https://github.com/analyst-collective/dbt/pull/256))
-- add pep8 check to continuous integration tests and bring codebase into compliance ([#257](https://github.com/analyst-collective/dbt/pull/257))
-
-## dbt release 0.6.0
-
-### tl;dr
- - Macros
- - More control over how models are materialized
- - Minor improvements
- - Bugfixes
- - Connor McArthur
-
-### Macros
-
-Macros are snippets of SQL that can be called like functions in models. Macros make it possible to re-use SQL between models
-in keeping with the engineering principle of DRY (Dont Repeat Yourself). Moreover, packages can expose Macros that you can use in your own dbt project.
-
-For detailed information on how to use Macros, check out the pull request [here](https://github.com/analyst-collective/dbt/pull/245)
-
-
-### Runtime Materialization Configs
-DBT Version 0.6.0 introduces two new ways to control the materialization of models:
-
-#### Non-destructive dbt run [more info](https://github.com/analyst-collective/dbt/issues/137)
-
-If you provide the `--non-destructive` argument to `dbt run`, dbt will minimize the amount of time during which your models are unavailable. Specfically, dbt
-will
- 1. Ignore models materialized as `views`
- 2. Truncate tables and re-insert data instead of dropping and re-creating
-
-This flag is useful for recurring jobs which only need to update table models and incremental models.
-
-```bash
-dbt run --non-destructive
-```
-
-#### Incremental Model Full Refresh [more info](https://github.com/analyst-collective/dbt/issues/140)
-
-If you provide the `--full-refresh` argument to `dbt run`, dbt will treat incremental models as table models. This is useful when
-
-1. An incremental model schema changes and you need to recreate the table accordingly
-2. You want to reprocess the entirety of the incremental model because of new logic in the model code
-
-```bash
-dbt run --full-refresh
-```
-
-Note that `--full-refresh` and `--non-destructive` can be used together!
-
-For more information, run
-```
-dbt run --help
-```
-
-### Minor improvements [more info](https://github.com/analyst-collective/dbt/milestone/15?closed=1)
-
-#### Add a `{{ target }}` variable to the dbt runtime [more info](https://github.com/analyst-collective/dbt/issues/149)
-Use `{{ target }}` to interpolate profile variables into your model definitions. For example:
-
-```sql
--- only use the last week of data in development
-select * from events
-
-{% if target.name == 'dev' %}
-where created_at > getdate() - interval '1 week'
-{% endif %}
-```
-
-#### User-specified `profiles.yml` dir [more info](https://github.com/analyst-collective/dbt/issues/213)
-DBT looks for a file called `profiles.yml` in the `~/.dbt/` directory. You can now overide this directory with
-```bash
-$ dbt run --profiles-dir /path/to/my/dir
-```
-#### Add timestamp to console output [more info](https://github.com/analyst-collective/dbt/issues/125)
-Informative _and_ pretty
-
-#### Run dbt from subdirectory of project root [more info](https://github.com/analyst-collective/dbt/issues/129)
-A story in three parts:
-```bash
-cd models/snowplow/sessions
-vim sessions.sql
-dbt run # it works!
-```
-
-#### Pre and post run hooks [more info](https://github.com/analyst-collective/dbt/issues/226)
-```yaml
-# dbt_project.yml
-name: ...
-version: ...
-
-...
-
-# supply either a string, or a list of strings
-on-run-start: "create table public.cool_table (id int)"
-on-run-end:
-  - insert into public.cool_table (id) values (1), (2), (3)
-  - insert into public.cool_table (id) values (4), (5), (6)
-```
-
-### Bug fixes
-
-We fixed 10 bugs in this release! See the full list [here](https://github.com/analyst-collective/dbt/milestone/11?closed=1)
-
----
-
-## dbt release 0.5.4
-
-### tl;dr
-- added support for custom SQL data tests
-  - SQL returns 0 results --> pass
-  - SQL returns > 0 results --> fail
-- dbt-core integration tests
-  - running in Continuous Integration environments
-    - windows ([appveyor](https://ci.appveyor.com/project/DrewBanin/dbt/branch/development))
-    - linux ([circle](https://circleci.com/gh/analyst-collective/dbt/tree/master))
-  - with [code coverage](https://circleci.com/api/v1/project/analyst-collective/dbt/latest/artifacts/0/$CIRCLE_ARTIFACTS/htmlcov/index.html?branch=development)
-
-
-### Custom SQL data tests
-
-Schema tests have proven to be an essential part of a modern analytical workflow. These schema tests validate basic constraints about your data. Namely: not null, unique, accepted value, and foreign key relationship properties can be asserted using schema tests.
-
-With dbt v0.5.4, you can now write your own custom "data tests". These data tests are SQL SELECT statements that return 0 rows on success, or > 0 rows on failure. A typical data test might look like:
-
-```sql
--- tests/assert_less_than_5_pct_event_cookie_ids_are_null.sql
-
--- If >= 5% of cookie_ids are null, then the test returns 1 row (failure).
--- If < 5% of cookie_ids are null, then the test returns 0 rows (success)
-
-with calc as (
-
-    select
-      sum(case when cookie_id is null then 1 else 0 end)::float / count(*)::float as fraction
-    from {{ ref('events') }}
-
-)
-
-select * from calc where fraction < 0.05
-```
-
-To enable data tests, add the `test-paths` config to your `dbt_project.yml` file:
-
-```yml
-name: 'Vandelay Industries`
-version: '1.0'
-
-source-paths: ["models"]
-target-path: "target"
-test-paths: ["tests"]        # look for *.sql files in the "tests" directory
-....
-```
-
-Any `.sql` file found in the `test-paths` director(y|ies) will be evaluated as data tests. These tests can be run with:
-
-```bash
-dbt test # run schema + data tests
-dbt test --schema # run only schema tests
-dbt test --data # run only data tests
-dbt test --data --schema # run schema + data tests
-
-# For more information, try
-dbt test -h
-```
-
-### DBT-core integration tests
-
-With the dbt 0.5.4 release, dbt now features a robust integration test suite. These integration tests will help mitigate the risk of software regressions, and in so doing, will help us develop dbt more quickly. You can check out the tests [here](https://github.com/analyst-collective/dbt/tree/development/test/integration), and the test results [here (linux/osx)](https://circleci.com/gh/analyst-collective/dbt/tree/master) and [here (windows)](https://ci.appveyor.com/project/DrewBanin/dbt/branch/development).
-
-
-### The Future
-
-You can check out the DBT roadmap [here](https://github.com/analyst-collective/dbt/milestones). In the next few weeks, we'll be working on [bugfixes](https://github.com/analyst-collective/dbt/milestone/11), [minor features](https://github.com/analyst-collective/dbt/milestone/15), [improved macro support](https://github.com/analyst-collective/dbt/milestone/14), and  [expanded control over runtime materialization configs](https://github.com/analyst-collective/dbt/milestone/9).
-
-As always, feel free to reach out to us on [Slack](http://ac-slackin.herokuapp.com/) with any questions or comments!
-
----
-
-## dbt release 0.5.3
-
-Bugfix release.
-
-Fixes regressions introduced in 0.5.1 and 0.5.2.
-
-### Fixed 0.5.1 regressions
-Incremental models were broken by the new column expansion feature. Column expansion is implemented as
-```sql
-alter table ... add column tmp_col varchar({new_size});
-update ... set tmp_col = existing_col
-alter table ... drop column existing_col
-alter table ... rename tmp_col to existing_col
-```
-
-This has the side-effect of moving the `existing_col` to the "end" of the table. When an incremental model tries to
-```sql
-insert into {table} (
-   select * from tmp_table
-)
-```
-suddenly the columns in `{table}` are incongruent with the columns in `tmp_table`. This insert subsequently fails.
-
-The fix for this issue is twofold:
-
-1. If the incremental model table DOES NOT already exist, avoid inserts altogether. Instead, run a `create table as (...)` statement
-2. If the incremental model table DOES already exist, query for the columns in the existing table and use those to build the insert statement, eg:
-
-```sql
-insert into "dbt_dbanin"."sessions" ("session_end_tstamp", "session_start_tstamp", ...)
-(
-    select "session_end_tstamp", "session_start_tstamp", ...
-    from "sessions__dbt_incremental_tmp"
-);
-```
-
-In this way, the source and destination columns are guaranteed to be in the same order!
-
-### Fixed 0.5.2 regressions
-
-We attempted to refactor the way profiles work in dbt. Previously, a default `user` profile was loaded, and the profiles specified in `dbt_project.yml` or on the command line (`with --profile`) would be applied on top of the `user` config. This implementation is [some of the earliest code](https://github.com/analyst-collective/dbt/commit/430d12ad781a48af6a754442693834efdf98ffb1) that was committed to dbt.
-
-As `dbt` has grown, we found this implementation to be a little unwieldy and hard to maintain. The 0.5.2 release made it so that only one profile could be loaded at a time. This profile needed to be specified in either `dbt_project.yml` or on the command line with `--profile`. A bug was errantly introduced during this change which broke the handling of dependency projects.
-
-### The future
-
-The additions of automated testing and a more comprehensive manual testing process will go a long way to ensuring the future stability of dbt. We're going to get started on these tasks soon, and you can follow our progress here: https://github.com/analyst-collective/dbt/milestone/16 .
-
-As always, feel free to [reach out to us on Slack](http://ac-slackin.herokuapp.com/) with any questions or concerns:
-
-
-
-
----
-
-## dbt release 0.5.2
-
-Patch release fixing a bug that arises when profiles are overridden on the command line with the `--profile` flag.
-
-See https://github.com/analyst-collective/dbt/releases/tag/v0.5.1
-
----
-
-## dbt release 0.5.1
-
-### 0. tl;dr
-
-1. Raiders of the Lost Archive -- version your raw data to make historical queries more accurate
-2. Column type resolution for incremental models (no more `Value too long for character type` errors)
-3. Postgres support
-4. Top-level configs applied to your project + all dependencies
-5. --threads CLI option + better multithreaded output
-
-### 1. Source table archival https://github.com/analyst-collective/dbt/pull/183
-
-Commonly, analysts need to "look back in time" at some previous state of data in their mutable tables. Imagine a `users` table which is synced to your data warehouse from a production database. This `users` table is a representation of what your users look like _now_. Consider what happens if you need to look at revenue by city for each of your users trended over time. Specifically, what happens if a user moved from, say, Philadelphia to New York? To do this correctly, you need to archive snapshots of the `users` table on a recurring basis. With this release, dbt now provides an easy mechanism to store such snapshots.
-
-To use this new feature, declare the tables you want to archive in your `dbt_project.yml` file:
-
-```yaml
-archive:
-    - source_schema: synced_production_data  # schema to look for tables in (declared below)
-      target_schema: dbt_archive             # where to archive the data to
-      tables:                                # list of tables to archive
-        - source_table: users                # table to archive
-          target_table: users_archived       # table to insert archived data into
-          updated_at: updated_at             # used to determine when data has changed
-          unique_key: id                     # used to generate archival query
-
-        - source_table: some_other_table
-           target_table: some_other_table_archive
-           updated_at: "updatedAt"
-           unique_key: "expressions || work || LOWER(too)"
-
-    - source_schema: some_other_schema
-      ....
-```
-
-The archived tables will mirror the schema of the source tables they're generated from. In addition, three fields are added to the archive table:
-
-1. `valid_from`: The timestamp when this archived row was inserted (and first considered valid)
-1. `valid_to`: The timestamp when this archived row became invalidated. The first archived record for a given `unique_key` has `valid_to = NULL`. When newer data is archived for that `unique_key`, the `valid_to` field of the old record is set to the `valid_from` field of the new record!
-1. `scd_id`: A unique key generated for each archive record. Scd = [Slowly Changing Dimension](https://en.wikipedia.org/wiki/Slowly_changing_dimension#Type_2:_add_new_row).
-
-dbt models can be built on top of these archived tables. The most recent record for a given `unique_key` is the one where `valid_to` is `null`.
-
-To run this archive process, use the command `dbt archive`. After testing and confirming that the archival works, you should schedule this process through cron (or similar).
-
-### 2. Incremental column expansion https://github.com/analyst-collective/dbt/issues/175
-
-Incremental tables are a powerful dbt feature, but there was at least one edge case which makes working with them difficult. During the first run of an incremental model, Redshift will infer a type for every column in the table. Subsequent runs can insert new data which does not conform to the expected type. One example is a `varchar(16)` field which is inserted into a `varchar(8)` field.
-In practice, this error looks like:
-
-```
-Value too long for character type
-DETAIL:
-  -----------------------------------------------
-  error:  Value too long for character type
-  code:      8001
-  context:   Value too long for type character varying(8)
-  query:     3743263
-  location:  funcs_string.hpp:392
-  process:   query4_35 [pid=18194]
-  -----------------------------------------------
-```
-
-With this release, dbt will detect when column types are incongruent and will attempt to reconcile these different types if possible. Specifically, dbt will alter the incremental model table schema from `character varying(x)` to `character varying(y)` for some `y > x`. This should drastically reduce the occurrence of this class of error.
-
-### 3. First-class Postgres support https://github.com/analyst-collective/dbt/pull/183
-
-With this release, Postgres became a first-class dbt target. You can configure a postgres database target in your `~/.dbt/profiles.yml` file:
-
-```yaml
-warehouse:
-  outputs:
-    dev:
-      type: postgres    # configure a target for Postgres
-      host: localhost
-      user: Drew
-      ....
-  run-target: dev
-```
-
-While Redshift is built on top of Postgres, the two are subtly different. For instance, Redshift supports sort and dist keys, while Postgres does not! dbt will use the database target `type` parameter to generate the appropriate SQL for the target database.
-
-### 4. Root-level configs https://github.com/analyst-collective/dbt/issues/161
-
-Configurations in `dbt_project.yml` can now be declared at the `models:` level. These configurations will apply to the primary project, as well as any dependency projects. This feature is particularly useful for setting pre- or post- hooks that run for *every* model. In practice, this looks like:
-
-```yaml
-name: 'My DBT Project'
-
-models:
-    post-hook:
-        - "grant select on {{this}} to looker_user"     # Applied to 'My DBT Project' and 'Snowplow' dependency
-    'My DBT Project':
-        enabled: true
-    'Snowplow':
-        enabled: true
-```
-
-### 5. --threads CLI option https://github.com/analyst-collective/dbt/issues/143
-
-The number of threads that DBT uses can now be overridden with a CLI argument. The number of threads used must be between 1 and 8.
-
-```bash
-dbt run --threads 1    # fine
-# or
-dbt run --threads 4    # great
-# or
-dbt run --threads 42    # too many!
-```
-
-In addition to this new CLI argument, the output from multi-threaded dbt runs should be a little more orderly now. Models won't show as `START`ed until they're actually queued to run. Previously, the output here was a little confusing. Happy threading!
-
-### Upgrading
-
-To upgrade to version 0.5.1 of dbt, run:
-
-``` bash
-pip install --upgrade dbt
-```
-
-### And another thing
-
-- Join us on [slack](http://ac-slackin.herokuapp.com/) with questions or comments
-
-Made with ♥️ by 🐟🏙  📈
-
----
-
-### 0. tl;dr
-
-- use a temp table when executing incremental models
-- arbitrary configuration (using config variables)
-- specify branches for dependencies
-- more & better docs
-
-### 1. new incremental model generation https://github.com/analyst-collective/dbt/issues/138
-
-In previous versions of dbt, an edge case existed which caused the `sql_where` query to select different rows in the `delete` and `insert` steps. As a result, it was possible to construct incremental models which would insert duplicate records into the specified table. With this release, DBT uses a temp table which will 1) circumvent this issue and 2) improve query performance. For more information, check out the GitHub issue: https://github.com/analyst-collective/dbt/issues/138
-
-### 2. Arbitrary configuration https://github.com/analyst-collective/dbt/issues/146
-
-Configuration in dbt is incredibly powerful: it is what allows models to change their behavior without changing their code. Previously, all configuration was done using built-in parameters, but that actually limits the user in the power of configuration.
-
-With this release, you can inject variables from `dbt_project.yml` into your top-level and dependency models. In practice, variables work like this:
-
-```yml
-# dbt_project.yml
-
-models:
-  my_project:
-    vars:
-      exclude_ip: '192.168.1.1'
-```
-
-```sql
--- filtered_events.sql
-
--- source code
-select * from public.events where ip_address != '{{ var("exclude_ip") }}'
-
--- compiles to
-select * from public.events where ip_address != '192.168.1.1'
-```
-
-The `vars` parameter in `dbt_project.yml` is compiled, so you can use jinja templating there as well! The primary use case for this is specifying "input" models to a dependency.
-
-Previously, dependencies used `ref(...)` to select from a project's base models. That interface was brittle, and the idea that dependency code had unbridled access to all of your top-level models made us a little uneasy. As of this release, we're deprecating the ability for dependencies to `ref(...)` top-level models. Instead, the recommended way for this to work is with vars! An example:
-
-```sql
--- dbt_modules/snowplow/models/events.sql
-
-select * from {{ var('snowplow_events_table') }}
-```
-
-and
-
-```yml
-models:
-  Snowplow:
-    vars:
-      snowplow_events_table: "{{ ref('base_events') }}"
-```
-
-This effectively mirrors the previous behavior, but it much more explicit about what's happening under the hood!
-
-### 3. specify a dependency branch https://github.com/analyst-collective/dbt/pull/165
-
-With this release, you can point DBT to a specific branch of a dependency repo. The syntax looks like this:
-
-```
-repositories:
-    - https://github.com/analyst-collective/dbt-audit.git@development # use the "development" branch
-```
-
-### 4. More & Better Docs!
-
-Check em out! And let us know if there's anything you think we can improve upon!
-
-
-### Upgrading
-
-To upgrade to version 0.5.0 of dbt, run:
-
-``` bash
-pip install --upgrade dbt
-```
-
----
-
-### 0. tl;dr
-
-- `--version` command
-- pre- and post- run hooks
-- windows support
-- event tracking
-
-
-### 1. --version https://github.com/analyst-collective/dbt/issues/135
-
-The `--version` command was added to help aid debugging. Further, organizations can use it to ensure that everyone in their org is up-to-date with dbt.
-
-```bash
-$ dbt --version
-installed version: 0.4.7
-   latest version: 0.4.7
-Up to date!
-```
-
-### 2. pre-and-post-hooks https://github.com/analyst-collective/dbt/pull/147
-
-With this release, you can now specify `pre-` and `post-` hooks that are run before and after a model is run, respectively. Hooks are useful for running `grant` statements, inserting a log of runs into an audit table, and more! Here's an example of a grant statement implemented using a post-hook:
-
-```yml
-models:
-  my_project:
-    post-hook: "grant select on table {{this}} to looker_user"
-    my_model:
-       materialized: view
-    some_model:
-      materialized: table
-      post-hook: "insert into my_audit_table (model_name, run_at) values ({{this.name}}, getdate())"
-```
-
-Hooks are recursively appended, so the `my_model` model will only receive the `grant select...` hook, whereas the `some_model` model will receive _both_ the `grant select...` and `insert into...` hooks.
-
-Finally, note that the `grant` statement uses the (hopefully familiar) `{{this}}` syntax whereas the `insert` statement uses the `{{this.name}}` syntax. When DBT creates a model:
- - A temp table is created
- - The original model is dropped
- - The temp table is renamed to the final model name
-
-DBT will intelligently uses the right table/view name when you invoke `{{this}}`, but you have a couple of more specific options available if you need them:
-
-```
-{{this}} : "schema"."table__dbt_tmp"
-{{this.schema}}: "schema"
-{{this.table}}: "table__dbt_tmp"
-{{this.name}}: "table"
-```
-
-### 3. Event tracking https://github.com/analyst-collective/dbt/issues/89
-
-We want to build the best version of DBT possible, and a crucial part of that is understanding how users work with DBT. To this end, we've added some really simple event tracking to DBT (using Snowplow). We do not track credentials, model contents or model names (we consider these private, and frankly none of our business). This release includes basic event tracking that reports 1) when dbt is invoked 2) when models are run, and 3) basic platform information (OS + python version). The schemas for these events can be seen [here](https://github.com/analyst-collective/dbt/tree/development/events/schemas/com.fishtownanalytics)
-
-You can opt out of event tracking at any time by adding the following to the top of you `~/.dbt/profiles.yml` file:
-
-```yaml
-config:
-    send_anonymous_usage_stats: False
-```
-
-### 4. Windows support https://github.com/analyst-collective/dbt/pull/154
-
-![windows](https://pbs.twimg.com/profile_images/571398080688181248/57UKydQS.png)
-
----
-
-dbt v0.4.1 provides improvements to incremental models, performance improvements, and ssh support for db connections.
-
-### 0. tl;dr
-
-- slightly modified dbt command structure
-- `unique_key` setting for incremental models
-- connect to your db over ssh
-- no more model-defaults
-- multithreaded schema tests
-
-If you encounter an SSL/cryptography error while upgrading to this version of dbt, check that your version of pip is up-to-date
-
-```bash
-pip install -U pip
-pip install -U dbt
-```
-
-### 1. new dbt command structure https://github.com/analyst-collective/dbt/issues/109
-```bash
-# To run models
-dbt run # same as before
-
-# to dry-run models
-dbt run --dry # previously dbt test
-
-# to run schema tests
-dbt test # previously dbt test --validate
-```
-
-### 2. Incremental model improvements https://github.com/analyst-collective/dbt/issues/101
-
-Previously, dbt calculated "new" incremental records to insert by querying for rows which matched some `sql_where` condition defined in the model configuration. This works really well for atomic datasets like a clickstream event log -- once inserted, these records will never change. Other datasets, like a sessions table comprised of many pageviews for many users, can change over time. Consider the following scenario:
-
-User 1 Session 1 Event 1 @ 12:00
-User 1 Session 1 Event 2 @ 12:01
--- dbt run --
-User 1 Session 1 Event 3 @ 12:02
-
-In this scenario, there are two possible outcomes depending on the `sql_where` chosen: 1) Event 3 does not get included in the Session 1 record for User 1 (bad), or 2) Session 1 is duplicated in the sessions table (bad). Both of these outcomes are inadequate!
-
-With this release, you can now add a `unique_key` expression to an incremental model config. Records matching the `unique_key` will be `delete`d from the incremental table, then `insert`ed as usual. This makes it possible to maintain data accuracy without recalculating the entire table on every run.
-
-The `unique_key` can be any expression which uniquely defines the row, eg:
-```yml
-sessions:
-  materialized: incremental
-  sql_where: "session_end_tstamp > (select max(session_end_tstamp) from {{this}})"
-  unique_key: user_id || session_index
-```
-
-### 3. Run schema validations concurrently https://github.com/analyst-collective/dbt/issues/100
-
-The `threads` run-target config now applies to schema validations too. Try it with `dbt test`
-
-### 4. Connect to database over ssh https://github.com/analyst-collective/dbt/issues/93
-
-Add an `ssh-host` parameter to a run-target to connect to a database over ssh. The `ssh-host` parameter should be the name of a `Host` in your `~/.ssh/config` file [more info](http://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/)
-
-```yml
-warehouse:
-  outputs:
-    dev:
-      type: redshift
-      host: my-redshift.amazonaws.com
-      port: 5439
-      user: my-user
-      pass: my-pass
-      dbname: my-db
-      schema: dbt_dbanin
-      threads: 8
-      ssh-host: ssh-host-name  # <------ Add this line
-  run-target: dev
-```
-
-### Remove the model-defaults config https://github.com/analyst-collective/dbt/issues/111
-
-The `model-defaults` config doesn't make sense in a dbt world with dependencies. To apply default configs to your package, add the configs immediately under the package definition:
-
-```yml
-models:
-    My_Package:
-        enabled: true
-        materialized: table
-        snowplow:
-            ...
-```
-
----
-
-## dbt v0.4.0
-
-dbt v0.4.0 provides new ways to materialize models in your database.
-
-### 0. tl;dr
- - new types of materializations: `incremental` and `ephemeral`
- - if upgrading, change `materialized: true|false` to `materialized: table|view|incremental|ephemeral`
- - optionally specify model configs within the SQL file
-
-### 1. Feature: `{{this}}` template variable https://github.com/analyst-collective/dbt/issues/81
-The `{{this}}` template variable expands to the name of the model being compiled. For example:
-
-```sql
--- my_model.sql
-select 'the fully qualified name of this model is {{ this }}'
--- compiles to
-select 'the fully qualified name of this model is "the_schema"."my_model"'
-```
-
-### 2. Feature: `materialized: incremental` https://github.com/analyst-collective/dbt/pull/90
-
-After initially creating a table, incremental models will `insert` new records into the table on subsequent runs. This drastically speeds up execution time for large, append-only datasets.
-
-Each execution of dbt run will:
- - create the model table if it doesn't exist
- - insert new records into the table
-
-New records are identified by a `sql_where` model configuration option. In practice, this looks like:
-
-```yml
-
-sessions:
-    materialized: incremental
-    sql_where: "session_start_time > (select max(session_start_time) from {{this}})"
-```
-
-There are a couple of new things here. Previously, `materialized` could either be set to `true` or `false`. Now, the valid options include `view`, `table,` `incremental`, and `ephemeral` (more on this last one below). Also note that incremental models generally require use of the {{this}} template variable to identify new records.
-
-The `sql_where` field is supplied as a `where` condition on a subquery containing the model definition. This resultset is then inserted into the target model. This looks something like:
-
-```sql
-insert into schema.model (
-    select * from (
-        -- compiled model definition
-    ) where {{sql_where}}
-)
-```
-
-### 3. Feature: `materialized: ephemeral` https://github.com/analyst-collective/dbt/issues/78
-
-Ephemeral models are injected as CTEs (`with` statements) into any model that `ref`erences them. Ephemeral models are part of the dependency graph and generally function like any other model, except ephemeral models are not compiled to their own files or directly created in the database. This is useful for intermediary models which are shared by other downstream models, but shouldn't be queried directly from outside of dbt.
-
-To make a model ephemeral:
-
-```yml
-employees:
-    materialized: ephemeral
-```
-
-Suppose you wanted to exclude `employees` from your `users` table, but you don't want to clutter your analytics schema with an `employees` table.
-
-```sql
--- employees.sql
-select * from public.employees where is_deleted = false
-
--- users.sql
-select *
-from {{ref('users')}}
-where email not in (select email from {{ref('employees')}})
-```
-
-The compiled SQL would look something like:
-```sql
-with __dbt__CTE__employees as (
-  select * from public.employees where is_deleted = false
-)
-select *
-from users
-where email not in (select email from __dbt__CTE__employees)
-```
-
-Ephemeral models play nice with other ephemeral models, incremental models, and regular table/view models. Feel free to mix and match different materialization options to optimize for performance and simplicity.
-
-
-### 4. Feature: In-model configs https://github.com/analyst-collective/dbt/issues/88
-
-Configurations can now be specified directly inside of models. These in-model configs work exactly the same as configs inside of the dbt_project.yml file.
-
-An in-model-config looks like this:
-
-```sql
--- users.sql
-
--- python function syntax
-{{ config(materialized="incremental", sql_where="id > (select max(id) from {{this}})") }}
--- OR json syntax
-{{
-    config({"materialized:" "incremental", "sql_where" : "id > (select max(id) from {{this}})"})
-}}
-
-select * from public.users
-```
-
-The config resolution order is:
-  1. dbt_project.yml `model-defaults`
-  2. in-model config
-  3. dbt_project.yml `models` config
-
-### 5. Fix: dbt seed null values https://github.com/analyst-collective/dbt/issues/102
-
-Previously, `dbt seed` would insert empty CSV cells as `"None"`, whereas they should have been `NULL`. Not anymore!
-
-
----
-
-## dbt v0.3.0
-
-Version 0.3.0 comes with the following updates:
-
-#### 1. Parallel model creation https://github.com/analyst-collective/dbt/pull/83
-dbt will analyze the model dependency graph and can create models in parallel if possible. In practice, this can significantly speed up the amount of time it takes to complete `dbt run`. The number of threads dbt uses must be between 1 and 8. To configure the number of threads dbt uses, add the `threads` key to your dbt target in `~/.dbt/profiles.yml`, eg:
-
-```yml
-user:
-  outputs:
-    my-redshift:
-      type: redshift
-      threads: 4         # execute up to 4 models concurrently
-      host: localhost
-      ...
-  run-target: my-redshift
-```
-
-For a complete example, check out [a sample profiles.yml file](https://github.com/analyst-collective/dbt/blob/master/sample.profiles.yml)
-
-#### 2. Fail only within a single dependency chain https://github.com/analyst-collective/dbt/issues/63
-If a model cannot be created, it won't crash the entire `dbt run` process. The errant model will fail and all of its descendants will be "skipped". Other models which do not depend on the failing model (or its descendants) will still be created.
-
-#### 3. Logging https://github.com/analyst-collective/dbt/issues/64, https://github.com/analyst-collective/dbt/issues/65
-dbt will log output from the `dbt run` and `dbt test` commands to a configurable logging directory. By default, this directory is called `logs/`. The log filename is `dbt.log` and it is rotated on a daily basic. Logs are kept for 7 days.
-
-To change the name of the logging directory, add the following line to your `dbt_project.yml` file:
-```yml
-log-path: "my-logging-directory" # will write logs to my-logging-directory/dbt.log
-```
-
-#### 4. Minimize time models are unavailable in the database https://github.com/analyst-collective/dbt/issues/68
-Previously, dbt would create models by:
-1. dropping the existing model
-2. creating the new model
-
-This resulted in a significant amount of time in which the model was inaccessible to the outside world. Now, dbt creates models by:
-1. creating a temporary model `{model-name}__dbt_tmp`
-2. dropping the existing model
-3. renaming the tmp model name to the actual model name
-
-#### 5. Arbitrarily deep nesting https://github.com/analyst-collective/dbt/issues/50
-Previously, all models had to be located in a directory matching `models/{model group}/{model_name}.sql`. Now, these models can be nested arbitrarily deeply within a given dbt project. For instance, `models/snowplow/sessions/transformed/transformed_sessions.sql` is a totally valid model location with this release.
-
-To configure these deeply-nested models, just nest the config options within the `dbt_project.yml` file. The only caveat is that you need to specify the dbt project name as the first key under the `models` object, ie:
-
-```yml
-models:
-  'Your Project Name':
-    snowplow:
-      sessions:
-        transformed:
-          transformed_sessions:
-            enabled: true
-```
-
-More information is available on the [issue](https://github.com/analyst-collective/dbt/issues/50) and in the [sample dbt_project.yml file](https://github.com/analyst-collective/dbt/blob/master/sample.dbt_project.yml)
-
-#### 6. don't try to create a schema if it already exists https://github.com/analyst-collective/dbt/issues/66
-dbt run would execute `create schema if not exists {schema}`. This would fail if the dbt user didn't have sufficient permissions to create the schema, even if the schema already existed! Now, dbt checks for the schema existence and only attempts to create the schema if it doesn't already exist.
-
-#### 7. Semantic Versioning
-The previous release of dbt was v0.2.3.0 which isn't a semantic version. This and all future dbt releases will conform to semantic version in the format `{major}.{minor}.{patch}`.
----
-
-## dbt v0.2.3.0
-Version 0.2.3.0 of dbt comes with the following updates:
-
-#### 1. Fix: Flip referential integrity arguments (breaking)
-Referential integrity validations in a `schema.yml` file were previously defined relative to the *parent* table:
-```yaml
-account:
-  constraints:
-    relationships:
-      - {from: id, to: people, field: account_id}
-```
-
-Now, these validations are specified relative to the *child* table
-```yaml
-people:
-  constraints:
-    relationships:
-      - {from: account_id, to: accounts, field: id}
-```
-
-For more information, run `dbt test -h`
-
-#### 2. Feature: seed tables from a CSV
-Previously, auxiliary data needed to be shoehorned into a view comprised of union statements, eg.
-```sql
-select 22 as "type", 'Chat Transcript' as type_name, 'chatted via olark' as event_name union all
-select 21, 'Custom Redirect', 'clicked a custom redirect' union all
-select 6, 'Email', 'email sent' union all
-...
-```
-
-That's not a scalable solution. Now you can load CSV files into your data warehouse:
-1. Add a CSV file (with a header) to the `data/` directory
-2. Run `dbt seed` to create a table from the CSV file!
-3. The table name with be the filename (sans `.csv`) and it will be placed in your `run-target`'s schema
-
-Subsequent calls to `dbt seed` will truncate the seeded tables (if they exist) and re-insert the data. If the table schema changes, you can run `dbt seed --drop-existing` to drop the table and recreate it.
-
-For more information, run `dbt seed -h`
-
-#### 3. Feature: compile analytical queries
-
-Versioning your SQL models with dbt is a great practice, but did you know that you can also version your analyses? Any SQL files in the `analysis/` dir will be compiled (ie. table names will be interpolated) and placed in the `target/build-analysis/` directory. These analytical queries will _not_ be run against your data warehouse with `dbt run` -- you should copy/paste them into the data analysis tool of your choice.
-
-#### 4. Feature: accepted values validation
-
-In your `schema.yml` file, you can now add `accepted-values` validations:
-```yaml
-accounts:
-  constraints:
-    accepted-values:
-      - {field: type, values: ['paid', 'free']}
-```
-
-This test will determine how many records in the `accounts` model have a `type` other than `paid` or `free`.
-
-#### 5. Feature: switch profiles and targets on the command line
-
-Switch between profiles with `--profile [profile-name]` and switch between run-targets with `--target [target-name]`.
-
-Targets should be something like "prod" or "dev" and profiles should be something like "my-org" or "my-side-project"
-
-```yaml
-side-project:
-  outputs:
-    prod:
-      type: redshift
-      host: localhost
-      port: 5439
-      user: Drew
-      pass:
-      dbname: data_generator
-      schema: ac_drew
-    dev:
-      type: redshift
-      host: localhost
-      port: 5439
-      user: Drew
-      pass:
-      dbname: data_generator
-      schema: ac_drew_dev
-  run-target: dev
-```
-
-To compile models using the `dev` environment of my `side-project` profile:
-`$ dbt compile --profile side-project --target dev`
-or for `prod`:
-`$ dbt compile --profile side-project --target prod`
-
-You can also add a "profile' config to the `dbt_config.yml` file to fix a dbt project to a specific profile:
-
-```yaml
-...
-test-paths: ["test"]
-data-paths: ["data"]
-
-# Fix this project to the "side-project" profile
-# You can still use --target to switch between environments!
-profile: "side-project"
-
-model-defaults:
-....
-```
+# dbt Core Changelog
+
+- This file provides a full account of all changes to `dbt-core` and `dbt-postgres`
+- Changes are listed under the (pre)release in which they first appear. Subsequent releases include changes from previous releases.
+- "Breaking changes" listed under a version may require action from end users or external maintainers when upgrading to that version.
+- Do not edit this file directly. This file is auto-generated using [changie](https://github.com/miniscruff/changie). For details on how to document a change, see [the contributing guide](https://github.com/dbt-labs/dbt-core/blob/main/CONTRIBUTING.md#adding-changelog-entry)
+
+## Previous Releases
+
+For information on prior major and minor releases, see their changelogs:
+
+
+* [1.4](https://github.com/dbt-labs/dbt-core/blob/1.4.latest/CHANGELOG.md)
+* [1.3](https://github.com/dbt-labs/dbt-core/blob/1.3.latest/CHANGELOG.md)
+* [1.2](https://github.com/dbt-labs/dbt-core/blob/1.2.latest/CHANGELOG.md)
+* [1.1](https://github.com/dbt-labs/dbt-core/blob/1.1.latest/CHANGELOG.md)
+* [1.0](https://github.com/dbt-labs/dbt-core/blob/1.0.latest/CHANGELOG.md)
+* [0.21](https://github.com/dbt-labs/dbt-core/blob/0.21.latest/CHANGELOG.md)
+* [0.20](https://github.com/dbt-labs/dbt-core/blob/0.20.latest/CHANGELOG.md)
+* [0.19](https://github.com/dbt-labs/dbt-core/blob/0.19.latest/CHANGELOG.md)
+* [0.18](https://github.com/dbt-labs/dbt-core/blob/0.18.latest/CHANGELOG.md)
+* [0.17](https://github.com/dbt-labs/dbt-core/blob/0.17.latest/CHANGELOG.md)
+* [0.16](https://github.com/dbt-labs/dbt-core/blob/0.16.latest/CHANGELOG.md)
+* [0.15](https://github.com/dbt-labs/dbt-core/blob/0.15.latest/CHANGELOG.md)
+* [0.14](https://github.com/dbt-labs/dbt-core/blob/0.14.latest/CHANGELOG.md)
+* [0.13](https://github.com/dbt-labs/dbt-core/blob/0.13.latest/CHANGELOG.md)
+* [0.12](https://github.com/dbt-labs/dbt-core/blob/0.12.latest/CHANGELOG.md)
+* [0.11 and earlier](https://github.com/dbt-labs/dbt-core/blob/0.11.latest/CHANGELOG.md)

CONTRIBUTING.md

@@ -0,0 +1,233 @@
+# Contributing to `dbt-core`
+
+`dbt-core` is open source software. It is what it is today because community members have opened issues, provided feedback, and [contributed to the knowledge loop](https://www.getdbt.com/dbt-labs/values/). Whether you are a seasoned open source contributor or a first-time committer, we welcome and encourage you to contribute code, documentation, ideas, or problem statements to this project.
+
+1. [About this document](#about-this-document)
+2. [Getting the code](#getting-the-code)
+3. [Setting up an environment](#setting-up-an-environment)
+4. [Running `dbt` in development](#running-dbt-core-in-development)
+5. [Testing dbt-core](#testing)
+6. [Debugging](#debugging)
+7. [Adding a changelog entry](#adding-a-changelog-entry)
+8. [Submitting a Pull Request](#submitting-a-pull-request)
+
+## About this document
+
+There are many ways to contribute to the ongoing development of `dbt-core`, such as by participating in discussions and issues. We encourage you to first read our higher-level document: ["Expectations for Open Source Contributors"](https://docs.getdbt.com/docs/contributing/oss-expectations).
+
+The rest of this document serves as a more granular guide for contributing code changes to `dbt-core` (this repository). It is not intended as a guide for using `dbt-core`, and some pieces assume a level of familiarity with Python development (virtualenvs, `pip`, etc). Specific code snippets in this guide assume you are using macOS or Linux and are comfortable with the command line.
+
+If you get stuck, we're happy to help! Drop us a line in the `#dbt-core-development` channel in the [dbt Community Slack](https://community.getdbt.com).
+
+### Notes
+
+- **Adapters:** Is your issue or proposed code change related to a specific [database adapter](https://docs.getdbt.com/docs/available-adapters)? If so, please open issues, PRs, and discussions in that adapter's repository instead. The sole exception is Postgres; the `dbt-postgres` plugin lives in this repository (`dbt-core`).
+- **CLA:** Please note that anyone contributing code to `dbt-core` must sign the [Contributor License Agreement](https://docs.getdbt.com/docs/contributor-license-agreements). If you are unable to sign the CLA, the `dbt-core` maintainers will unfortunately be unable to merge any of your Pull Requests. We welcome you to participate in discussions, open issues, and comment on existing ones.
+- **Branches:** All pull requests from community contributors should target the `main` branch (default). If the change is needed as a patch for a minor version of dbt that has already been released (or is already a release candidate), a maintainer will backport the changes in your PR to the relevant "latest" release branch (`1.0.latest`, `1.1.latest`, ...). If an issue fix applies to a release branch, that fix should be first committed to the development branch and then to the release branch (rarely release-branch fixes may not apply to `main`).
+- **Releases**: Before releasing a new minor version of Core, we prepare a series of alphas and release candidates to allow users (especially employees of dbt Labs!) to test the new version in live environments. This is an important quality assurance step, as it exposes the new code to a wide variety of complicated deployments and can surface bugs before official release. Releases are accessible via pip, homebrew, and dbt Cloud.
+
+## Getting the code
+
+### Installing git
+
+You will need `git` in order to download and modify the `dbt-core` source code. On macOS, the best way to download git is to just install [Xcode](https://developer.apple.com/support/xcode/).
+
+### External contributors
+
+If you are not a member of the `dbt-labs` GitHub organization, you can contribute to `dbt-core` by forking the `dbt-core` repository. For a detailed overview on forking, check out the [GitHub docs on forking](https://help.github.com/en/articles/fork-a-repo). In short, you will need to:
+
+1. Fork the `dbt-core` repository
+2. Clone your fork locally
+3. Check out a new branch for your proposed changes
+4. Push changes to your fork
+5. Open a pull request against `dbt-labs/dbt-core` from your forked repository
+
+### dbt Labs contributors
+
+If you are a member of the `dbt-labs` GitHub organization, you will have push access to the `dbt-core` repo. Rather than forking `dbt-core` to make your changes, just clone the repository, check out a new branch, and push directly to that branch. Branch names should be fixed by `CT-XXX/` where:
+* CT stands for 'core team'
+* XXX stands for a JIRA ticket number
+
+## Setting up an environment
+
+There are some tools that will be helpful to you in developing locally. While this is the list relevant for `dbt-core` development, many of these tools are used commonly across open-source python projects.
+
+### Tools
+
+These are the tools used in `dbt-core` development and testing:
+
+- [`tox`](https://tox.readthedocs.io/en/latest/) to manage virtualenvs across python versions. We currently target the latest patch releases for Python 3.7, 3.8, 3.9, 3.10 and 3.11
+- [`pytest`](https://docs.pytest.org/en/latest/) to define, discover, and run tests
+- [`flake8`](https://flake8.pycqa.org/en/latest/) for code linting
+- [`black`](https://github.com/psf/black) for code formatting
+- [`mypy`](https://mypy.readthedocs.io/en/stable/) for static type checking
+- [`pre-commit`](https://pre-commit.com) to easily run those checks
+- [`changie`](https://changie.dev/) to create changelog entries, without merge conflicts
+- [`make`](https://users.cs.duke.edu/~ola/courses/programming/Makefiles/Makefiles.html) to run multiple setup or test steps in combination. Don't worry too much, nobody _really_ understands how `make` works, and our Makefile aims to be super simple.
+- [GitHub Actions](https://github.com/features/actions) for automating tests and checks, once a PR is pushed to the `dbt-core` repository
+
+A deep understanding of these tools in not required to effectively contribute to `dbt-core`, but we recommend checking out the attached documentation if you're interested in learning more about each one.
+
+#### Virtual environments
+
+We strongly recommend using virtual environments when developing code in `dbt-core`. We recommend creating this virtualenv
+in the root of the `dbt-core` repository. To create a new virtualenv, run:
+```sh
+python3 -m venv env
+source env/bin/activate
+```
+
+This will create and activate a new Python virtual environment.
+
+#### Docker and `docker-compose`
+
+Docker and `docker-compose` are both used in testing. Specific instructions for you OS can be found [here](https://docs.docker.com/get-docker/).
+
+
+#### Postgres (optional)
+
+For testing, and later in the examples in this document, you may want to have `psql` available so you can poke around in the database and see what happened. We recommend that you use [homebrew](https://brew.sh/) for that on macOS, and your package manager on Linux. You can install any version of the postgres client that you'd like. On macOS, with homebrew setup, you can run:
+
+```sh
+brew install postgresql
+```
+
+## Running `dbt-core` in development
+
+### Installation
+
+First make sure that you set up your `virtualenv` as described in [Setting up an environment](#setting-up-an-environment).  Also ensure you have the latest version of pip installed with `pip install --upgrade pip`. Next, install `dbt-core` (and its dependencies):
+
+```sh
+make dev
+```
+or, alternatively:
+```sh
+pip install -r dev-requirements.txt -r editable-requirements.txt
+pre-commit install
+```
+
+When installed in this way, any changes you make to your local copy of the source code will be reflected immediately in your next `dbt` run.
+
+### Running `dbt-core`
+
+With your virtualenv activated, the `dbt` script should point back to the source code you've cloned on your machine. You can verify this by running `which dbt`. This command should show you a path to an executable in your virtualenv.
+
+Configure your [profile](https://docs.getdbt.com/docs/configure-your-profile) as necessary to connect to your target databases. It may be a good idea to add a new profile pointing to a local Postgres instance, or a specific test sandbox within your data warehouse if appropriate.
+
+## Testing
+
+Once you're able to manually test that your code change is working as expected, it's important to run existing automated tests, as well as adding some new ones. These tests will ensure that:
+- Your code changes do not unexpectedly break other established functionality
+- Your code changes can handle all known edge cases
+- The functionality you're adding will _keep_ working in the future
+
+Although `dbt-core` works with a number of different databases, you won't need to supply credentials for every one of these databases in your test environment. Instead, you can test most `dbt-core` code changes with Python and Postgres.
+
+### Initial setup
+
+Postgres offers the easiest way to test most `dbt-core` functionality today. They are the fastest to run, and the easiest to set up. To run the Postgres integration tests, you'll have to do one extra step of setting up the test database:
+
+```sh
+make setup-db
+```
+or, alternatively:
+```sh
+docker-compose up -d database
+PGHOST=localhost PGUSER=root PGPASSWORD=password PGDATABASE=postgres bash test/setup_db.sh
+```
+
+### Test commands
+
+There are a few methods for running tests locally.
+
+#### Makefile
+
+There are multiple targets in the Makefile to run common test suites and code
+checks, most notably:
+
+```sh
+# Runs unit tests with py38 and code checks in parallel.
+make test
+# Runs postgres integration tests with py38 in "fail fast" mode.
+make integration
+```
+> These make targets assume you have a local installation of a recent version of [`tox`](https://tox.readthedocs.io/en/latest/) for unit/integration testing and pre-commit for code quality checks,
+> unless you use choose a Docker container to run tests. Run `make help` for more info.
+
+Check out the other targets in the Makefile to see other commonly used test
+suites.
+
+#### `pre-commit`
+[`pre-commit`](https://pre-commit.com) takes care of running all code-checks for formatting and linting. Run `make dev` to install `pre-commit` in your local environment (we recommend running this command with a python virtual environment active). This command installs several pip executables including black, mypy, and flake8. Once this is done you can use any of the linter-based make targets as well as a git pre-commit hook that will ensure proper formatting and linting.
+
+#### `tox`
+
+[`tox`](https://tox.readthedocs.io/en/latest/) takes care of managing virtualenvs and install dependencies in order to run tests. You can also run tests in parallel, for example, you can run unit tests for Python 3.7, Python 3.8, Python 3.9, Python 3.10 and Python 3.11 checks in parallel with `tox -p`. Also, you can run unit tests for specific python versions with `tox -e py37`. The configuration for these tests in located in `tox.ini`.
+
+#### `pytest`
+
+Finally, you can also run a specific test or group of tests using [`pytest`](https://docs.pytest.org/en/latest/) directly. With a virtualenv active and dev dependencies installed you can do things like:
+
+```sh
+# run all unit tests in a file
+python3 -m pytest test/unit/test_graph.py
+# run a specific unit test
+python3 -m pytest test/unit/test_graph.py::GraphTest::test__dependency_list
+# run specific Postgres integration tests (old way)
+python3 -m pytest -m profile_postgres test/integration/074_postgres_unlogged_table_tests
+# run specific Postgres integration tests (new way)
+python3 -m pytest tests/functional/sources
+```
+
+> See [pytest usage docs](https://docs.pytest.org/en/6.2.x/usage.html) for an overview of useful command-line options.
+
+### Unit, Integration, Functional?
+
+Here are some general rules for adding tests:
+* unit tests (`test/unit` & `tests/unit`) don’t need to access a database; "pure Python" tests should be written as unit tests
+* functional tests (`test/integration` & `tests/functional`) cover anything that interacts with a database, namely adapter
+* *everything in* `test/*` *is being steadily migrated to* `tests/*`
+
+## Debugging
+
+1. The logs for a `dbt run` have stack traces and other information for debugging errors (in `logs/dbt.log` in your project directory).
+2. Try using a debugger, like `ipdb`. For pytest: `--pdb --pdbcls=IPython.terminal.debugger:pdb`
+3. Sometimes, it’s easier to debug on a single thread: `dbt --single-threaded run`
+4. To make print statements from Jinja macros:  `{{ log(msg, info=true) }}`
+5. You can also add `{{ debug() }}` statements, which will drop you into some auto-generated code that the macro wrote.
+6. The dbt “artifacts” are written out to the ‘target’ directory of your dbt project. They are in unformatted json, which can be hard to read. Format them with:
+> python -m json.tool target/run_results.json > run_results.json
+
+### Assorted development tips
+* Append `# type: ignore` to the end of a line if you need to disable `mypy` on that line.
+* Sometimes flake8 complains about lines that are actually fine, in which case you can put a comment on the line such as: # noqa or # noqa: ANNN, where ANNN is the error code that flake8 issues.
+* To collect output for `CProfile`, run dbt with the `-r` option and the name of an output file, i.e. `dbt -r dbt.cprof run`. If you just want to profile parsing, you can do: `dbt -r dbt.cprof parse`. `pip` install `snakeviz` to view the output. Run `snakeviz dbt.cprof` and output will be rendered in a browser window.
+
+## Adding or modifying a CHANGELOG Entry
+
+We use [changie](https://changie.dev) to generate `CHANGELOG` entries. **Note:** Do not edit the `CHANGELOG.md` directly. Your modifications will be lost.
+
+Follow the steps to [install `changie`](https://changie.dev/guide/installation/) for your system.
+
+Once changie is installed and your PR is created for a new feature, simply run the following command and changie will walk you through the process of creating a changelog entry:
+
+```shell
+changie new
+```
+
+Commit the file that's created and your changelog entry is complete!
+
+If you are contributing to a feature already in progress, you will modify the changie yaml file in dbt/.changes/unreleased/ related to your change. If you need help finding this file, please ask within the discussion for the pull request!
+
+You don't need to worry about which `dbt-core` version your change will go into. Just create the changelog entry with `changie`, and open your PR against the `main` branch. All merged changes will be included in the next minor version of `dbt-core`. The Core maintainers _may_ choose to "backport" specific changes in order to patch older minor versions. In that case, a maintainer will take care of that backport after merging your PR, before releasing the new version of `dbt-core`.
+
+## Submitting a Pull Request
+
+Code can be merged into the current development branch `main` by opening a pull request. A `dbt-core` maintainer will review your PR. They may suggest code revision for style or clarity, or request that you add unit or integration test(s). These are good things! We believe that, with a little bit of help, anyone can contribute high-quality code.
+
+Automated tests run via GitHub Actions. If you're a first-time contributor, all tests (including code checks and unit tests) will require a maintainer to approve. Changes in the `dbt-core` repository trigger integration tests against Postgres. dbt Labs also provides CI environments in which to test changes to other adapters, triggered by PRs in those adapters' repositories, as well as periodic maintenance checks of each adapter in concert with the latest `dbt-core` code changes.
+
+Once all tests are passing and your PR has been approved, a `dbt-core` maintainer will merge your changes into the active development branch. And that's it! Happy developing :tada:
+
+Sometimes, the content license agreement auto-check bot doesn't find a user's entry in its roster. If you need to force a rerun, add `@cla-bot check` in a comment on the pull request.

Dockerfile

@@ -1,14 +0,0 @@
-FROM python:3.6
-
-RUN apt-get update
-
-RUN apt-get install -y python-pip netcat
-RUN apt-get install -y python-dev python3-dev
-
-RUN pip install pip --upgrade
-RUN pip install virtualenv
-RUN pip install virtualenvwrapper
-RUN pip install tox
-
-WORKDIR /usr/src/app
-RUN cd /usr/src/app

Dockerfile.test

@@ -0,0 +1,86 @@
+##
+#  This dockerfile is used for local development and adapter testing only.
+#  See `/docker` for a generic and production-ready docker file
+##
+
+FROM ubuntu:23.04
+
+ENV DEBIAN_FRONTEND noninteractive
+
+RUN apt-get update \
+    && apt-get install -y --no-install-recommends \
+    software-properties-common \
+    && add-apt-repository ppa:git-core/ppa -y \
+    && apt-get dist-upgrade -y \
+    && apt-get install -y --no-install-recommends \
+    netcat \
+    postgresql \
+    curl \
+    git \
+    ssh \
+    software-properties-common \
+    make \
+    build-essential \
+    ca-certificates \
+    libpq-dev \
+    libsasl2-dev \
+    libsasl2-2 \
+    libsasl2-modules-gssapi-mit \
+    libyaml-dev \
+    unixodbc-dev \
+    && add-apt-repository ppa:deadsnakes/ppa \
+    && apt-get install -y \
+    python \
+    python-dev \
+    python3-pip \
+    python3.6 \
+    python3.6-dev \
+    python3-pip \
+    python3.6-venv \
+    python3.7 \
+    python3.7-dev \
+    python3.7-venv \
+    python3.8 \
+    python3.8-dev \
+    python3.8-venv \
+    python3.9 \
+    python3.9-dev \
+    python3.9-venv \
+    python3.10 \
+    python3.10-dev \
+    python3.10-venv \
+    python3.11 \
+    python3.11-dev \
+    python3.11-venv \
+    && apt-get clean \
+    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*
+
+ARG DOCKERIZE_VERSION=v0.6.1
+RUN curl -LO https://github.com/jwilder/dockerize/releases/download/$DOCKERIZE_VERSION/dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz \
+    && tar -C /usr/local/bin -xzvf dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz \
+    && rm dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz
+
+RUN pip3 install -U tox wheel six setuptools
+
+# These args are passed in via docker-compose, which reads then from the .env file.
+# On Linux, run `make .env` to create the .env file for the current user.
+# On MacOS and Windows, these can stay unset.
+ARG USER_ID
+ARG GROUP_ID
+
+RUN if [ ${USER_ID:-0} -ne 0 ] && [ ${GROUP_ID:-0} -ne 0 ]; then \
+    groupadd -g ${GROUP_ID} dbt_test_user && \
+    useradd -m -l -u ${USER_ID} -g ${GROUP_ID} dbt_test_user; \
+    else \
+    useradd -mU -l dbt_test_user; \
+    fi
+RUN mkdir /usr/app && chown dbt_test_user /usr/app
+RUN mkdir /home/tox && chown dbt_test_user /home/tox
+
+WORKDIR /usr/app
+VOLUME /usr/app
+
+USER dbt_test_user
+
+ENV PYTHONIOENCODING=utf-8
+ENV LANG C.UTF-8

License.md

@@ -186,7 +186,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright {yyyy} {name of copyright owner}
+   Copyright 2021 dbt Labs, Inc.
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.

Makefile

@@ -1,28 +1,136 @@
-.PHONY: install test test-unit test-integration
+.DEFAULT_GOAL:=help
 
-changed_tests := `git status --porcelain | grep '^\(M\| M\|A\| A\)' | awk '{ print $$2 }' | grep '\/test_[a-zA-Z_\-\.]\+.py'`
+# Optional flag to run target in a docker container.
+# (example `make test USE_DOCKER=true`)
+ifeq ($(USE_DOCKER),true)
+	DOCKER_CMD := docker-compose run --rm test
+endif
 
-install:
-	pip install .
+#
+# To override CI_flags, create a file at this repo's root dir named `makefile.test.env`. Fill it
+# with any ENV_VAR overrides required by your test environment, e.g.
+#    DBT_TEST_USER_1=user
+#    LOG_DIR="dir with a space in it"
+#
+# Warn: Restrict each line to one variable only.
+#
+ifeq (./makefile.test.env,$(wildcard ./makefile.test.env))
+	include ./makefile.test.env
+endif
 
-it:
-	@echo "Unit test run starting..."
-	@time docker-compose run test tox -e unit-py27,pep8
+CI_FLAGS =\
+	DBT_TEST_USER_1=$(if $(DBT_TEST_USER_1),$(DBT_TEST_USER_1),dbt_test_user_1)\
+	DBT_TEST_USER_2=$(if $(DBT_TEST_USER_2),$(DBT_TEST_USER_2),dbt_test_user_2)\
+	DBT_TEST_USER_3=$(if $(DBT_TEST_USER_3),$(DBT_TEST_USER_3),dbt_test_user_3)\
+	RUSTFLAGS=$(if $(RUSTFLAGS),$(RUSTFLAGS),"-D warnings")\
+	LOG_DIR=$(if $(LOG_DIR),$(LOG_DIR),./logs)\
+	DBT_LOG_FORMAT=$(if $(DBT_LOG_FORMAT),$(DBT_LOG_FORMAT),json)
 
-test:
-	@echo "Full test run starting..."
-	@time docker-compose run test tox
 
-test-unit:
-	@echo "Unit test run starting..."
-	@time docker-compose run test tox -e unit-py27,unit-py35,pep8
+.PHONY: dev_req
+dev_req: ## Installs dbt-* packages in develop mode along with only development dependencies.
+	@\
+	pip install -r dev-requirements.txt -r editable-requirements.txt
 
-test-integration:
-	@echo "Integration test run starting..."
-	@time docker-compose run test tox -e integration-postgres-py27,integration-postgres-py35,integration-snowflake-py27,integration-snowflake-py35
+.PHONY: dev
+dev: dev_req ## Installs dbt-* packages in develop mode along with development dependencies and pre-commit.
+	@\
+	pre-commit install
 
-test-new:
-	@echo "Test run starting..."
-	@echo "Changed test files:"
-	@echo "${changed_tests}"
-	@docker-compose run test /usr/src/app/test/runner.sh ${changed_tests}
+.PHONY: mypy
+mypy: .env ## Runs mypy against staged changes for static type checking.
+	@\
+	$(DOCKER_CMD) pre-commit run --hook-stage manual mypy-check | grep -v "INFO"
+
+.PHONY: flake8
+flake8: .env ## Runs flake8 against staged changes to enforce style guide.
+	@\
+	$(DOCKER_CMD) pre-commit run --hook-stage manual flake8-check | grep -v "INFO"
+
+.PHONY: black
+black: .env ## Runs black  against staged changes to enforce style guide.
+	@\
+	$(DOCKER_CMD) pre-commit run --hook-stage manual black-check -v | grep -v "INFO"
+
+.PHONY: lint
+lint: .env ## Runs flake8 and mypy code checks against staged changes.
+	@\
+	$(DOCKER_CMD) pre-commit run flake8-check --hook-stage manual | grep -v "INFO"; \
+	$(DOCKER_CMD) pre-commit run mypy-check --hook-stage manual | grep -v "INFO"
+
+.PHONY: unit
+unit: .env ## Runs unit tests with py
+	@\
+	$(DOCKER_CMD) tox -e py
+
+.PHONY: test
+test: .env ## Runs unit tests with py and code checks against staged changes.
+	@\
+	$(DOCKER_CMD) tox -e py; \
+	$(DOCKER_CMD) pre-commit run black-check --hook-stage manual | grep -v "INFO"; \
+	$(DOCKER_CMD) pre-commit run flake8-check --hook-stage manual | grep -v "INFO"; \
+	$(DOCKER_CMD) pre-commit run mypy-check --hook-stage manual | grep -v "INFO"
+
+.PHONY: integration
+integration: .env ## Runs postgres integration tests with py-integration
+	@\
+	$(CI_FLAGS) $(DOCKER_CMD) tox -e py-integration -- -nauto
+
+.PHONY: integration-fail-fast
+integration-fail-fast: .env ## Runs postgres integration tests with py-integration in "fail fast" mode.
+	@\
+	$(DOCKER_CMD) tox -e py-integration -- -x -nauto
+
+.PHONY: interop
+interop: clean
+	@\
+	mkdir $(LOG_DIR) && \
+	$(CI_FLAGS) $(DOCKER_CMD) tox -e py-integration -- -nauto && \
+	LOG_DIR=$(LOG_DIR) cargo run --manifest-path test/interop/log_parsing/Cargo.toml
+
+.PHONY: setup-db
+setup-db: ## Setup Postgres database with docker-compose for system testing.
+	@\
+	docker-compose up -d database && \
+	PGHOST=localhost PGUSER=root PGPASSWORD=password PGDATABASE=postgres bash test/setup_db.sh
+
+# This rule creates a file named .env that is used by docker-compose for passing
+# the USER_ID and GROUP_ID arguments to the Docker image.
+.env: ## Setup step for using using docker-compose with make target.
+	@touch .env
+ifneq ($(OS),Windows_NT)
+ifneq ($(shell uname -s), Darwin)
+	@echo USER_ID=$(shell id -u) > .env
+	@echo GROUP_ID=$(shell id -g) >> .env
+endif
+endif
+
+.PHONY: clean
+clean: ## Resets development environment.
+	@echo 'cleaning repo...'
+	@rm -f .coverage
+	@rm -f .coverage.*
+	@rm -rf .eggs/
+	@rm -f .env
+	@rm -rf .tox/
+	@rm -rf build/
+	@rm -rf dbt.egg-info/
+	@rm -f dbt_project.yml
+	@rm -rf dist/
+	@rm -f htmlcov/*.{css,html,js,json,png}
+	@rm -rf logs/
+	@rm -rf target/
+	@find . -type f -name '*.pyc' -delete
+	@find . -type d -name '__pycache__' -depth -delete
+	@echo 'done.'
+
+
+.PHONY: help
+help: ## Show this help message.
+	@echo 'usage: make [target] [USE_DOCKER=true]'
+	@echo
+	@echo 'targets:'
+	@grep -E '^[8+a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}'
+	@echo
+	@echo 'options:'
+	@echo 'use USE_DOCKER=true to run target in a docker container'

README.md

@@ -1,31 +1,39 @@
-# dbt
+<p align="center">
+  <img src="https://raw.githubusercontent.com/dbt-labs/dbt-core/fa1ea14ddfb1d5ae319d5141844910dd53ab2834/etc/dbt-core.svg" alt="dbt logo" width="750"/>
+</p>
+<p align="center">
+  <a href="https://github.com/dbt-labs/dbt-core/actions/workflows/main.yml">
+    <img src="https://github.com/dbt-labs/dbt-core/actions/workflows/main.yml/badge.svg?event=push" alt="CI Badge"/>
+  </a>
+</p>
 
-dbt (data build tool) helps analysts write reliable, modular code using a workflow that closely mirrors software development.
+**[dbt](https://www.getdbt.com/)** enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.
 
----
+![architecture](https://github.com/dbt-labs/dbt-core/blob/202cb7e51e218c7b29eb3b11ad058bd56b7739de/etc/dbt-transform.png)
 
-- [What is dbt]?
-- Read the [dbt viewpoint]
-- [Installation]
-- Join the [chat][slack-url] on Slack for live questions and support.
+## Understanding dbt
 
-### Testing
+Analysts using dbt can transform their data by simply writing select statements, while dbt handles turning these statements into tables and views in a data warehouse.
 
-| service | development | master |
-| --- | --- | --- |
-| CircleCI| [![CircleCI](https://circleci.com/gh/analyst-collective/dbt/tree/development.svg?style=svg)](https://circleci.com/gh/analyst-collective/dbt/tree/development) | [![CircleCI](https://circleci.com/gh/analyst-collective/dbt/tree/master.svg?style=svg)](https://circleci.com/gh/analyst-collective/dbt/tree/master) |
-| AppVeyor | [![AppVeyor](https://ci.appveyor.com/api/projects/status/v01rwd3q91jnwp9m/branch/development?svg=true)](https://ci.appveyor.com/project/DrewBanin/dbt/branch/development) | [![AppVeyor](https://ci.appveyor.com/api/projects/status/v01rwd3q91jnwp9m/branch/master?svg=true)](https://ci.appveyor.com/project/DrewBanin/dbt/branch/master) |
+These select statements, or "models", form a dbt project. Models frequently build on top of one another – dbt makes it easy to [manage relationships](https://docs.getdbt.com/docs/ref) between models, and [visualize these relationships](https://docs.getdbt.com/docs/documentation), as well as assure the quality of your transformations through [testing](https://docs.getdbt.com/docs/testing).
 
-[Coverage](https://circleci.com/api/v1/project/analyst-collective/dbt/latest/artifacts/0/$CIRCLE_ARTIFACTS/htmlcov/index.html?branch=development)
+![dbt dag](https://raw.githubusercontent.com/dbt-labs/dbt-core/6c6649f9129d5d108aa3b0526f634cd8f3a9d1ed/etc/dbt-dag.png)
+
+## Getting started
+
+- [Install dbt](https://docs.getdbt.com/docs/get-started/installation)
+- Read the [introduction](https://docs.getdbt.com/docs/introduction/) and [viewpoint](https://docs.getdbt.com/docs/about/viewpoint/)
+
+## Join the dbt Community
+
+- Be part of the conversation in the [dbt Community Slack](http://community.getdbt.com/)
+- Read more on the [dbt Community Discourse](https://discourse.getdbt.com)
+
+## Reporting bugs and contributing code
+
+- Want to report a bug or request a feature? Let us know on [Slack](http://community.getdbt.com/), or open [an issue](https://github.com/dbt-labs/dbt-core/issues/new)
+- Want to help us build dbt? Check out the [Contributing Guide](https://github.com/dbt-labs/dbt-core/blob/HEAD/CONTRIBUTING.md)
 
 ## Code of Conduct
 
-Everyone interacting in the dbt project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the [PyPA Code of Conduct].
-
-
-
-[PyPA Code of Conduct]: https://www.pypa.io/en/latest/code-of-conduct/
-[slack-url]: http://ac-slackin.herokuapp.com/
-[Installation]: http://dbt.readthedocs.io/en/master/guide/setup/
-[What is dbt]: http://dbt.readthedocs.io/en/master/about/overview/
-[dbt viewpoint]: http://dbt.readthedocs.io/en/master/about/viewpoint/
+Everyone interacting in the dbt project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the [dbt Code of Conduct](https://community.getdbt.com/code-of-conduct).

RELEASE.md

@@ -1,78 +0,0 @@
-### Release Procedure :shipit:
-
-1. Update changelog
-1. Bumpversion
-1. Merge to master
-  - (on master) git pull origin development
-1. Deploy to pypi
-  - python setup.py sdist upload -r pypi
-1. Deploy to homebrew
-  - Make a pull request against homebrew-core
-1. Deploy to conda-forge
-  - Make a pull request against dbt-feedstock
-1. Git release notes (points to changelog)
-1. Post to slack (point to changelog)
-
-#### Homebrew Release Process
-
-1. fork homebrew and add a remote:
-
-```
-cd $(brew --repo homebrew/core)
-git remote add origin <your-github-username> <your-fork-url>
-```
-
-2. edit the formula.
-
-```bash
-brew update
-mkvirtualenv --python="$(which python3)" brew
-pip install homebrew-pypi-poet dbt
-diff "$(brew --repo homebrew/core)"/Formula/dbt.rb <(poet -f dbt)
-```
-
-find any differences in resource stanzas, and incorporate them into the formula
-
-```
-brew edit dbt
-...
-diff "$(brew --repo homebrew/core)"/Formula/dbt.rb <(poet -f dbt)
-```
-
-3. reinstall, test, and audit dbt. if the test or audit fails, fix the formula with step 1.
-
-```bash
-brew uninstall --force dbt
-brew install --build-from-source dbt
-brew test dbt
-brew audit --strict dbt
-```
-
-4. make a pull request for the change.
-
-```bash
-cd $(brew --repo homebrew/core)
-git pull origin master
-git checkout -b dbt-<version> origin/master
-git add . -p
-git commit -m 'dbt <version>'
-git push -u <your-github-username> dbt-<version>
-```
-
-#### Conda Forge Release Process
-
-1. Clone the fork of `conda-forge/dbt-feedstock` [here](https://github.com/fishtown-analytics/dbt-feedstock)
-```bash
-git clone git@github.com:fishtown-analytics/dbt-feedstock.git
-
-```
-2. Update the version and sha256 in `recipe/meta.yml`. To calculate the sha256, run:
-
-```bash
-wget https://github.com/analyst-collective/dbt/archive/v{version}.tar.gz
-openssl sha256 v{version}.tar.gz
-```
-
-3. Push the changes and create a PR against `conda-forge/dbt-feedstock`
-
-4. Confirm that all automated conda-forge tests are passing

appveyor.yml

@@ -1,63 +0,0 @@
-version: 1.0.{build}-{branch}
-
-environment:
-  # SDK v7.0 MSVC Express 2008's SetEnv.cmd script will fail if the
-  # /E:ON and /V:ON options are not enabled in the batch script intepreter
-  # See: http://stackoverflow.com/a/13751649/163740
-  CMD_IN_ENV: "cmd /E:ON /V:ON /C .\\appveyor\\run_with_env.cmd"
-  TOX_ENV: "pywin"
-
-  matrix:
-    - PYTHON: "C:\\Python35"
-      PYTHON_VERSION: "3.5.2"
-      PYTHON_ARCH: "32"
-
-    #- PYTHON: "C:\\Python35"
-    #  PYTHON_VERSION: "3.5.2"
-    #  PYTHON_ARCH: "32"
-
-  PGUSER: postgres
-  PGPASSWORD: Password12!
-
-services:
-  - postgresql94
-
-hosts:
-  database: 127.0.0.1
-
-init:
-  - PATH=C:\Program Files\PostgreSQL\9.4\bin\;%PATH%
-  - ps: Set-Content "c:\program files\postgresql\9.4\data\pg_hba.conf" "host   all   all   ::1/128        trust"
-  - ps: Add-Content "c:\program files\postgresql\9.4\data\pg_hba.conf" "host   all   all   127.0.0.1/32   trust"
-
-install:
-  # Download setup scripts and unzip
-  - ps: "wget https://github.com/cloudify-cosmo/appveyor-utils/archive/master.zip -OutFile ./master.zip"
-  - "7z e master.zip */appveyor/* -oappveyor"
-
-  # Install Python (from the official .msi of http://python.org) and pip when
-  # not already installed.
-  - "powershell ./appveyor/install.ps1"
-
-  # Prepend newly installed Python to the PATH of this build (this cannot be
-  # done from inside the powershell script as it would require to restart
-  # the parent CMD process).
-  - "SET PATH=%PYTHON%;%PYTHON%\\Scripts;%PATH%"
-
-  # Check that we have the expected version and architecture for Python
-  - "python --version"
-  - "python -c \"import struct; print(struct.calcsize('P') * 8)\""
-
-build: false  # Not a C# project, build stuff at the test step instead.
-
-before_test:
-  - "%CMD_IN_ENV% pip install psycopg2==2.6.2"
-  - "%CMD_IN_ENV% pip install tox"
-
-test_script:
-  - "bash test/setup_db.sh"
-
-  # this is generally a bad idea TODO
-  - git config --system http.sslverify false
-
-  - "%CMD_IN_ENV% tox -e %TOX_ENV%"

circle.yml

@@ -1,25 +0,0 @@
-machine:
-  python:
-    version: 3.6.0
-  post:
-    - pyenv global 2.7.12 3.6.0
-  hosts:
-    database: 127.0.0.1
-
-database:
-  override:
-    - bash test/setup_db.sh
-
-dependencies:
-  pre:
-    - pip install --upgrade pip setuptools || true
-    - pip install --upgrade tox tox-pyenv
-  override:
-    - pyenv local 2.7.12 3.6.0
-
-test:
-  override:
-    - sudo chown -R ubuntu:ubuntu /root/
-    - /bin/bash -c 'cd /home/ubuntu/dbt && tox'
-  post:
-    - mv htmlcov $CIRCLE_ARTIFACTS/

core/MANIFEST.in

@@ -0,0 +1,2 @@
+recursive-include dbt/include *.py *.sql *.yml *.html *.md .gitkeep .gitignore
+include dbt/py.typed

core/README.md

@@ -0,0 +1,39 @@
+<p align="center">
+  <img src="https://raw.githubusercontent.com/dbt-labs/dbt-core/fa1ea14ddfb1d5ae319d5141844910dd53ab2834/etc/dbt-core.svg" alt="dbt logo" width="750"/>
+</p>
+<p align="center">
+  <a href="https://github.com/dbt-labs/dbt-core/actions/workflows/main.yml">
+    <img src="https://github.com/dbt-labs/dbt-core/actions/workflows/main.yml/badge.svg?event=push" alt="CI Badge"/>
+  </a>
+</p>
+
+**[dbt](https://www.getdbt.com/)** enables data analysts and engineers to transform their data using the same practices that software engineers use to build applications.
+
+![architecture](https://raw.githubusercontent.com/dbt-labs/dbt-core/6c6649f9129d5d108aa3b0526f634cd8f3a9d1ed/etc/dbt-arch.png)
+
+## Understanding dbt
+
+Analysts using dbt can transform their data by simply writing select statements, while dbt handles turning these statements into tables and views in a data warehouse.
+
+These select statements, or "models", form a dbt project. Models frequently build on top of one another – dbt makes it easy to [manage relationships](https://docs.getdbt.com/docs/ref) between models, and [visualize these relationships](https://docs.getdbt.com/docs/documentation), as well as assure the quality of your transformations through [testing](https://docs.getdbt.com/docs/testing).
+
+![dbt dag](https://raw.githubusercontent.com/dbt-labs/dbt-core/6c6649f9129d5d108aa3b0526f634cd8f3a9d1ed/etc/dbt-dag.png)
+
+## Getting started
+
+- [Install dbt](https://docs.getdbt.com/docs/installation)
+- Read the [introduction](https://docs.getdbt.com/docs/introduction/) and [viewpoint](https://docs.getdbt.com/docs/about/viewpoint/)
+
+## Join the dbt Community
+
+- Be part of the conversation in the [dbt Community Slack](http://community.getdbt.com/)
+- Read more on the [dbt Community Discourse](https://discourse.getdbt.com)
+
+## Reporting bugs and contributing code
+
+- Want to report a bug or request a feature? Let us know on [Slack](http://community.getdbt.com/), or open [an issue](https://github.com/dbt-labs/dbt-core/issues/new)
+- Want to help us build dbt? Check out the [Contributing Guide](https://github.com/dbt-labs/dbt-core/blob/HEAD/CONTRIBUTING.md)
+
+## Code of Conduct
+
+Everyone interacting in the dbt project's codebases, issue trackers, chat rooms, and mailing lists is expected to follow the [dbt Code of Conduct](https://community.getdbt.com/code-of-conduct).

core/dbt/README.md

@@ -0,0 +1,60 @@
+# core/dbt directory README
+
+## The following are individual files in this directory.
+
+### compilation.py
+
+### constants.py
+
+### dataclass_schema.py
+
+### deprecations.py
+
+### exceptions.py
+
+### flags.py
+
+### helper_types.py
+
+### hooks.py
+
+### lib.py
+
+### links.py
+
+### logger.py
+
+### main.py
+
+### node_types.py
+
+### profiler.py
+
+### selected_resources.py
+
+### semver.py
+
+### tracking.py
+
+### ui.py
+
+### utils.py
+
+### version.py
+
+
+## The subdirectories will be documented in a README in the subdirectory
+* adapters
+* cli
+* clients
+* config
+* context
+* contracts
+* deps
+* docs
+* events
+* graph
+* include
+* parser
+* task
+* tests

core/dbt/__init__.py

@@ -0,0 +1,7 @@
+# N.B.
+# This will add to the package’s __path__ all subdirectories of directories on sys.path named after the package which effectively combines both modules into a single namespace (dbt.adapters)
+# The matching statement is in plugins/postgres/dbt/__init__.py
+
+from pkgutil import extend_path
+
+__path__ = extend_path(__path__, __name__)

core/dbt/adapters/README.md

@@ -0,0 +1,30 @@
+# Adapters README
+
+The Adapters module is responsible for defining database connection methods, caching information from databases, how relations are defined, and the two major connection types we have - base and sql.
+
+# Directories
+
+## `base`
+
+Defines the base implementation Adapters can use to build out full functionality.
+
+## `sql`
+
+Defines a sql implementation for adapters that initially inherits the above base implementation and  comes with some premade methods and macros that can be overwritten as needed per adapter. (most common type of adapter.)
+
+# Files
+
+## `cache.py`
+
+Cached information from the database.
+
+## `factory.py`
+Defines how we generate adapter objects
+
+## `protocol.py`
+
+Defines various interfaces for various adapter objects. Helps mypy correctly resolve methods.
+
+## `reference_keys.py`
+
+Configures naming scheme for cache elements to be universal.

core/dbt/adapters/__init__.py

@@ -0,0 +1,7 @@
+# N.B.
+# This will add to the package’s __path__ all subdirectories of directories on sys.path named after the package which effectively combines both modules into a single namespace (dbt.adapters)
+# The matching statement is in plugins/postgres/dbt/adapters/__init__.py
+
+from pkgutil import extend_path
+
+__path__ = extend_path(__path__, __name__)

core/dbt/adapters/base/README.md

@@ -0,0 +1,10 @@
+
+## Base adapters
+
+### impl.py
+
+The class `SQLAdapter` in [base/imply.py](https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/adapters/base/impl.py) is a (mostly) abstract object that adapter objects inherit from. The base class scaffolds out methods that every adapter project usually should implement for smooth communication between dbt and database.
+
+Some target databases require more or fewer methods--it all depends on what the warehouse's featureset is.
+
+Look into the class for function-level comments.