Add `dbt-assertions` package to hub

[AxelThevenot]

Description

dbt-assertions is a package designed for data testing capabilities at the row level integrated into the data pipeline flagging each row based on specific assertions it fails.

Link to your package's repository: https://github.com/AxelThevenot/dbt-assertions

Checklist

This checklist is a cut down version of the best practices that we have identified as the package hub has grown. Although meeting these checklist items is not a prerequisite to being added to the Hub, we have found that packages which don't conform provide a worse user experience.

First run experience

• [X] The package includes a README which explains how to get started with the package and customise its behaviour
• [X] The README indicates which data warehouses/platforms are expected to work with this package

Customisability

• [X] The package uses ref or source, instead of hard-coding table references.

  Packages for data transformation (delete if not relevant):

• [X] provide a mechanism (such as variables) to customise the location of source tables.
• [X] do not assume database/schema names in sources.

Dependencies

Dependencies on dbt Core

• [X] The package has set a supported require-dbt-version range in dbt_project.yml. Example: A package which depends on functionality added in dbt Core 1.2 should set its require-dbt-version property to [">=1.2.0", "<2.0.0"].

  Dependencies on other packages defined in packages.yml:

• [X] Dependencies are imported from the dbt Package Hub when available, as opposed to a git installation.
• [X] Dependencies contain the widest possible range of supported versions, to minimise issues in dependency resolution.
• [X] In particular, dependencies are not pinned to a patch version unless there is a known incompatibility.

  Interoperability

• [X] The package does not override dbt Core behaviour in such a way as to impact other dbt resources (models, tests, etc) not provided by the package.
• [X] The package uses the cross-database macros built into dbt Core where available, such as {{ dbt.except() }} and {{ dbt.type_string() }}.
• [X] The package disambiguates its resource names to avoid clashes with nodes that are likely to already exist in a project. For example, packages should not provide a model simply called users.

Versioning

• [X] (Required): The package's git tags validates against the regex defined in version.py
• [X] The package's version follows the guidance of Semantic Versioning 2.0.0. (Note in particular the recommendation for production-ready packages to be version 1.0.0 or above)

[AxelThevenot]

Update for a generic test and better documentation in 0.1.1 Everything ok now 😇

@joellabes , @dbeatty10

[AxelThevenot]

Oh my bad, let me change this during the day. I though it was a good idea but you're right

Thank you for the feedback I return to you as fast as possible

[AxelThevenot]

What about this image if I keep the for dbt part ? Good for you, @joellabes ? I'll update the documentation according to your answer, thank you 😄

[joellabes]

Thanks for the quick turnaround @AxelThevenot! I have checked internally, and the takeaway is that you can't use the logo at all - the relevant part of the trademark guidelines is:

You may use the word Marks, but not the logo Marks, to truthfully describe the relationship between your software or services and ours

However you could do something like this:

(as long as the word mark includes the ™, which your current version does)

or use the name dbt-assertions on its own because of this carve out:

dbt packages [...] may use the word mark “dbt” as part of the project name

Hopefully that makes sense - lmk if not, either here or @joellabes on the community Slack

[AxelThevenot]

Everything is now updated (image and install) Thank you very much for your feedbacks !

[joellabes]

YAY I am so excited to take this for a spin!

[AxelThevenot]

You'll tell me :)

I have an other package I create the PR