figure out a testing plan for dbt-materialize

[JLDLaughlin]

As dbt and Materialize evolve, one or both systems may make changes that break this adapter. If we're going to encourage anyone to use dbt-materialize, we should test it regularly.

I propose that we:

• Add a CI workflow to this repo that runs the materialize.dbtspec tests.
• Add the above tests to the Materialize release checklist - the release manager should just be able to trigger a manual run and tag me if something goes wrong.

@benesch - does this seem reasonable before I circulate it (particularly the release portion) more widely?

[benesch]

Definitely getting some automated tests going is a good plan! We release frequently enough though that I'm kind of leery of making the release checklist even longer than it already is. One option is, at the moment we're ready to say that breaking dbt-materialize needs to block a release, to move this repository into the main Materialize repository. That way we can verify on every PR that the dbt adapter doesn't break!

This all assumes there isn't a compelling reason for this to remain its own repository, of course.

[JLDLaughlin]

One option is, at the moment we're ready to say that breaking dbt-materialize needs to block a release, to move this repository into the main Materialize repository.

Sounds great to me! So updated proposal:

• Add a CI workflow to this repo that runs the materialize.dbtspec tests.
• When this adapter is stable, move to the main Materialize repository.