[CI] Introduce check-release-type CI workflow

[MichelleArk]

Housekeeping

• I am a maintainer of dbt-common

Short description

Our changelog entries are great for end-user facing changelogs, but for programmatic consumers of dbt-common (e.g. dbt-core & dbt-adapters) -- they do not always accurately signal what kind of interface changes are occurring and possibly breaking. Ideally, this is communicated via the versioning of dbt-common, but the person releasing dbt-common needs to know what version to release!

To that end, we'd like to introduce a lightweight CI check that would be required on any PR to dbt-common. The CI check would require one of release_type: major, release_type: minor, release_type: patch labels to be applied to the PR prior to merging. That way, the person releasing dbt-common could pick the highest release type among a set of changes and infer the version to release of dbt-common.

Until we do this, it will be very easy to release versions of dbt-common that are misleading in terms of their backward/forward compatibility and break previously released and stable versions of dbt-core and dbt-adapters. So it is high priority!

Acceptance criteria

Introduce a required CI check on PRs that passes if one of release_type: major, release_type: minor, release_type: patch labels exists, and fails otherwise

Suggested Tests

Manual testing of the CI workflow should be sufficient here

Impact to Other Teams

N/A

Will backports be required?

Nope

Context

No response

[ChenyuLInx]

In the long term maybe consider adding this information in the changelog so we can see the information more easily in the diff between the current and the last release.