add tox support for integration tests

[emmyoop]

Resolves #9

Summary of Changes

• Add tox with Postgres as target (dbt_integration_postgres)
• Add GitHub Action for running integration tests against Postgres via tox
• [Nice to have] Add dev-requirements.txt to install tox and latest dbt-core + dbt-postgres for local development/testing
• TODO: Set up integration tests for other adapters by adding to tox.ini + supported_adapters.env + GH workflow.
  • To be compatible with dbt Labs' continuous env vars need to match the naming convention described in Standardizing integration tests for popular dbt packages dbt-labs/dbt-core#10668.
  • This should enable you to fully remove integration tests running on CircleCI. (I have left integration_tests/ci/profiles.yml in place so that CircleCI can continue running unchanged in the meantime.)

Why Do We Need These Changes

As explained in #10668(dbt-labs/dbt-core#10668), by setting up tox as a standard entry-point, the Core development team at dbt Labs can include dbt-expectations integration tests (along with other popular dbt packages) as part of our continuous development & delivery of dbt.

Reviewers

@tpoll @gusvargas

[tpoll]

@emmyoop I think this makes sense -- is there any action on our side needed beyond merging this PR?

I think I'm a little confused what the expectation is here -- we need to move off of our circleCI tests and onto github actions? So I need to add our other supported adapters and move over all our CI into github action in the new format of this PR?

[emmyoop]

@tpoll we (dbt Labs) want to test the most popular packages that are used in dbt Cloud for compatibility before we upgrade our releases. The changes I'm suggesting put everything into the expected format so that we can run your tests with new images before we publish them.

We install your package from the Hub and test the adapters defined in supported_adapters.env, limited to the ones that are supported by dbt Cloud, in our own warehouses. This means before we start to test dbt-expectations, you will need to do a new release. Once you have set up testing and released a new version, we will automatically pick it up and begin testing it.

It is up to you if you continue to rely on CircleCI or not. I would encourage you to move to GitHub actions unless there is a strong reason to maintain both testing environments. The way this is designed, you should be able to continue your current testing pattern, just running in GitHub actions.

This PR only sets up postgres since it does not require any warehouse credentials. It runs inside the GitHub runner so I was able to get it running without any need to coordinate on credentials. I did not remove postgres from CircleCI because this is your repo and I want you to decide how to handle it. I am happy to add a commit that does remove postgres from CircleCI if you would prefer.

[tpoll]

@emmyoop okay, I'm just trying to understand what the next steps are for me as a maintainer to do. It sounds like they are

1. Merge this PR.
2. Do similar work to this PR to add our other supported packages of to github actions in the new format: e.g this same work for all

Snowflake
BigQuery
DuckDB
Spark
Trino

3. Cut a new release of dbt expectations

Is that what is expected of us? If so, is there any documentation or examples you can point us to that show the specific format and variable names that are expected for each adapter. Is this the PR I should use a reference https://github.com/dbt-labs/dbt-utils/pull/919/files?

[emmyoop]

@tpoll those steps sounds right!

dbt-labs/dbt-package-testing has examples of everything, down to the variables names and tox settings.

We do not support testing duckdb since it's not an available adapters in dbt Cloud.

However, if you look at run_tox.yml you should be able to pull out the important parts in this repo to be able to run duckdb (or any other non-cloud adapter). If you choose, you could of course also keep duckdb in CircleCI and the dbt Cloud supported adapters in GitHub.