The current behavior was to trigger goreleaser on any new tag pushed, and then goreleaser creates the release in github. Later,
we can manually edit the release notes after being automatically published.
The consequence of that is the trigger-publish.yml workflow, which depends on release published will not run.
The change is to make both get triggered on release published, i.e., after the release notes are added in the github UI+ pressed publish, so that both get the event. This also gives us more control, and allows tags that are not releases.
What was changed
The current behavior was to trigger goreleaser on any new tag pushed, and then goreleaser creates the release in github. Later, we can manually edit the release notes after being automatically published.
The problem with that strategy is that when you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run. See https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow This is a safety mechanism to avoid loops.
The consequence of that is the trigger-publish.yml workflow, which depends on release published will not run.
The change is to make both get triggered on release published, i.e., after the release notes are added in the github UI+ pressed publish, so that both get the event. This also gives us more control, and allows tags that are not releases.