@nick Please, feel free to suggest any improvements or other way how we can catch issues on actual release artifact.

Hi @nickfloyd
Our CI without this extra validation will not catch broken provider if a new tag is not based on main branch, like the last release.
It may help (at least my hope) to detect provider doesn't pass validation before new release will be done.

Hi @nickfloyd Our CI without this extra validation will not catch broken provider if a new tag is not based on main branch, like the last release. It may help (at least my hope) to detect provider doesn't pass validation before new release will be done.

Yeah (thank you for making this change), catching it before attempting releasing is the ideal - but with patches it has made things messy.

You are welcome and I really hope it may help to prevent to happen releases when this type of validation didn't pass.

We are as organization rely on this provider and I am interested to make my best to make it more stable.

I appreciate your work and happy to see that development is happening again.
There are some gaps and we are behind in such things like the latest go github client, Terraform framework and other aspects.

I see its actually even more tricky.
Our workflows are run from these patch branches and if new versions of workflows aren't merged it will run in context of this branch.

There is a need to get new release workflow in patch branch or make it to use reusable workflow from @main branch.
I'm afraid it will complicate CI if we start to introduce reusable workflows, but it may help for some use cases when patch branch is behind main. But still at least it should use reusable workflows to fetch new code of workflow from main.

@nickfloyd Maybe we need to add something to run tests on release event to do some regression when release has happened and it wasn't yet synced from hashicorp registry site.