Fix make test for running integration tests locally#591
Conversation
…pinned patch version)
| #### Set up profiles | ||
| Do either one of the following: | ||
| 1. Use `DBT_PROFILES_DIR` | ||
| ```shell | ||
| cp integration_tests/ci/sample.profiles.yml integration_tests/profiles.yml | ||
| export DBT_PROFILES_DIR=$(cd integration_tests && pwd) | ||
| ``` | ||
| 2. Use `~/.dbt/profiles.yml` | ||
| - Copy contents from `integration_tests/ci/sample.profiles.yml` into `~/.dbt/profiles.yml`. |
There was a problem hiding this comment.
When given the choice, I prefer including a profiles.yml file within each dbt project and then setting DBT_PROFILES_DIR. See example within run_test.sh
Of course this relies on profiles.yml to be completely devoid of actual secrets (which seems eminently doable since we can use environment variables instead).
Any cautions for me before I rename integration_tests/ci/sample.profiles.yml to integration_tests/profiles.yml?
| echo "Install dbt-$(target)..."; \ | ||
| pip install --upgrade pip setuptools; \ | ||
| pip install --pre "dbt-$(target)" -r dev-requirements.txt; |
There was a problem hiding this comment.
Do we want this to always be --pre? This will include pre-release versions of the dbt adapters (like release candidates).
Or would we want this to typically not include --pre by default, but allow it to be configurable?
| ### Configure credentials | ||
| Edit the env file for your TARGET in `integration_tests/.env/[TARGET].env`. |
There was a problem hiding this comment.
Do we want to consolidate all the integration_tests/.env/[TARGET].env files into a single test.env file instead?
| BIGQUERY_SERVICE_KEY_PATH= | ||
| BIGQUERY_TEST_DATABASE= No newline at end of file |
There was a problem hiding this comment.
I don't think there's anything preventing folks from accidentally committing secrets that they write to locations like integration_tests/.env/bigquery.env
| Load the environment variables: | ||
| ```shell | ||
| set -a; source integration_tests/.env/[TARGET].env; set +a | ||
| ``` | ||
|
|
||
| To run the integration tests on your local machine, like they will get run in the CI (using CircleCI), you can do the following: | ||
| or more specific: | ||
| ```shell | ||
| set -a; source integration_tests/.env/postgres.env; set +a |
There was a problem hiding this comment.
Is there any more preferable way to store and load environment variables containing secrets?
For non-secret project-specific environment variables, I like using direnv
|
Just trying out the examples in the README.md and still running into the issues. Looks like this test is failing after running through the examples in the PR. I'm thinking it is because the database source name is not getting correctly set. |
|
Yes, thanks for pointing that out, @robertdefilippi ! Doing it in this order worked for me, so I'm updating the instructions accordingly:
|
|
Ah makes sense! Thank you 🙂 |
Resolves #344 resolves #564
This is a:
All pull requests from community contributors should target the
mainbranch (default).How to try it out
fix/344-564-make-testintegration_tests/README.mdDescription & motivation
It should be possible to run integration tests locally by following a set of written instructions. There are instructions right now, but they don't work as written.
Implementation details
test-alltarget -- each adapter will need to be tested individuallyvenvcreation out of*.shscripts and into written instructions (similar to how dbt-core has it)integration_tests/.env/*to align with variable names in CircleCIChecklist
I have updated the README.md (if applicable)I have added tests & descriptions to my models (and macros if applicable)I have added an entry to CHANGELOG.md