release: move to goreleaser/actions for releases

[lbajolet-hashicorp]

Prior to this commit, new releases were done through a CircleCI that
would invoke a script to tag and release the latest version of the
repository on Github.

This is now replaced by goreleaser, which will do the same, and trigger
the CHANGELOG generation for the next version of the SDK.

[nywilken]

Thanks for making the update. I have a few suggestions but this is otherwise looks good.

[nywilken]

This will create a release for all tags. Let’s update it to only create a release for version tags v1.0.0.

    tags:
      - 'v[0-9]+.[0-9]+.[0-9]+*'

We also recently added permissions to the actions in Packer to limit the scope of a GitHub token. Let’s add it here as well.

permissions:
  # Allow creating GitHub release
  contents: write

[nywilken]

There have been a few plugin releases where the dependency bumps have been important call outs but excluded because of this config. Let’s remove it for the SDK

[lbajolet-hashicorp]

I understand why that'd be important yeah.
Since this was pretty much adapted from another plugin, and the issue may also apply there, do you think it'd make sense to replicate on other packer plugins too?

[nywilken]

Since this was pretty much adapted from another plugin, and the issue may also apply there, do you think it'd make sense to replicate on other packer plugins too?

This is a good question. At first I was a bit reluctant because the plugins have more dependencies then the SDK. So I was concerned about noise. But since it automatically generated it may not be bad to have them in the changelog. And if it becomes noise we can adjust per plugin. What do you think?

[nywilken]

Changes look great!

[lbajolet-hashicorp]

Since this was pretty much adapted from another plugin, and the issue may also apply there, do you think it'd make sense to replicate on other packer plugins too?

This is a good question. At first I was a bit reluctant because the plugins have more dependencies then the SDK. So I was concerned about noise. But since it automatically generated it may not be bad to have them in the changelog. And if it becomes noise we can adjust per plugin. What do you think?

I think it can be done as you suggest yes, if we find the output too noisy after a while we can revert the change on a per-plugin basis.

If we're not too sure about the volume of noise for every plugin, we can first test on a subset of them, see how things go for a while, and decide whether or not we want that rolled on all our other plugins?

From what I can see, this should be easily scriptable, we can roll this change on plugins soon if we want to try that

[nywilken]

From what I can see, this should be easily scriptable, we can roll this change on plugins soon if we want to try that

@lbajolet-hashicorp lets make it happen. I would prefer to do all plugins in one shot. Can you script this up and open the PRs please. I can review and merge.

[lbajolet-hashicorp]

Yessir, will do!