Add support for v1.5

[glsdown]

Overview

The release of v1.5 broke the upload_invocations macro. This fixes that issue as well as adds in some CI checks that will test the currently supported versions in turn (as well as test running on an empty table, which the double run doesn't test now).

I've additionally split the lint and test actions to try and add some clarity - we will need to add the relevant badge to the README once the lint action is ready.

Update type - breaking / non-breaking

• Minor bug fix
• Documentation improvements
• Quality of Life improvements
• New features (non-breaking change)
• New features (breaking change)
• Other (non-breaking change)
• Other (breaking change)

What does this solve?

• [Bug]: Invocations cannot be uploaded when using dbt-snowflake version 1.5.0 #296
• [Bug]: upload_invocations() fails on the dbt-databricks 1.5.0 #307

Outstanding questions

Will be interested to see the CI results here as it's not something I can test locally, I'm also not sure how to test it via CI properly either.

It would be good to know if there is a better way of creating the identical tox environments with different deps. It looks like you probably can do it, but I can't see exactly how.

What databases have you tested with?

• Snowflake
• Google BigQuery
• Databricks
• Spark
• N/A

[dluftspring]

👍 no issues here.

Documenting for future PRs because they aren't logically part of this fix

1. The shell script chaining that happens in our workflow steps between getting the file changes and calling sqlfluff lint probably has to go. We've copied it all over the place from our project template and it's not very readable. I'm 90% sure it's been done better in a marketplace action that will save us lines of code
2. More of a style thing. Do we want to combine the workflows into single yaml files based on which events trigger them. This is sort of how GitHub wants you to do it because then you can recycle the name of the status badges e.g."PR Workflows" would have job names "lint" and "test".

Point (1) I feel strongly about point (2) is a take it or leave it type thing but something we should at least look at. We choose between proliferation of yaml files or having long yaml files.