Add Snowflake internal build process workflow #931
Conversation
VersusFacit
force-pushed
the
add_release_internal_workflow
branch
from
42a52b2 to
27e9cdf
Compare
There was a problem hiding this comment.
All the same questions/changes from dbt-labs/dbt-redshift#732
| @@ -0,0 +1,6 @@ | |||
| kind: Features | |||
| body: ' Add new workflow for internal patch releases' | |||
There was a problem hiding this comment.
If adapters wants these changelogs
| body: ' Add new workflow for internal patch releases' | |
| body: 'Add new workflow for internal patch releases' |
There was a problem hiding this comment.
I've been tagging GH actions changes with Skip Changelog (since these aren't shipped to end users).
Do we want to do that here too?
| @@ -0,0 +1,6 @@ | |||
| kind: Features | |||
| body: ' Add new workflow for internal patch releases' | |||
There was a problem hiding this comment.
I've been tagging GH actions changes with Skip Changelog (since these aren't shipped to end users).
Do we want to do that here too?
| dbms_name: | ||
| description: "The name of the warehouse the adapter connects to." | ||
| type: string | ||
| default: "snowflake" |
There was a problem hiding this comment.
Would this ever be a value besides snowflake?
| package_test_command: | ||
| description: "Package test command" | ||
| type: string | ||
| default: "python -c \"import dbt.adapters.snowflake\"" |
There was a problem hiding this comment.
Nit; should we change this to import dbt.adapters as adapters; assert hasattr(adapters, 'snowflake') to make this a bit clearer?
| invoke-reusable-workflow: | ||
| name: Build and Release Internally | ||
|
|
||
| uses: VersusFacit/dbt-release/.github/workflows/internal-archive-release.yml@main |
There was a problem hiding this comment.
Should we migrate this workflow to the dbt-labs namespace before merging?
resolves 38 of epic
This PR adds a workflow file for bigquery testing. It is based on dbt-labs/dbt-redshift#732. I assume there will be some quirks to work out. Also, we'll need to add aws secrets.