chore(ci): delay release publish until after artifacts are attached #834
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have intermittently seen provider releases fail to show up in the Terraform registry. When that happens we can usually redeliver the GitHub release webhook event and get the registry to find the new release.
While working on changes to the Equinix Python SDK, it occurred to me that the webhook issues we are seeing might be related to how we do automatic releases. The semantic-release-action creates the GitHub release, and then the provider artifacts are built and uploaded by GoReleaser after the GitHub release has been created. The webhook event is sent to the Terraform registry when the release is created, not after the artifacts are uploaded; it's possible that the registry attempts to load the release only to find that it does not include a provider, and that that is why our provider releases sometimes do not show up in the registry right away.
This PR updates the semantic-release configuration so that semantic-release-action creates a draft release, and the release is not published until after GoReleaser builds and uploads the necessary artifacts. The release and publish steps are split into separate jobs in the release workflow so that we can more easily re-run specific parts of the workflow and easily skip the publish step if no new release was created. These changes may resolve our issues with releases not showing up in the registry, but even if they don't, this is still a worthwhile quality-of-life improvement for the release workflow.