Relying on tags to trigger workflows makes it hard to trace what's
happening after a release, currently:
1. We manually trigger a release workflow
2. The release workflow executes and tags the new release in code
3. Several other workflows trigger after matching the tag doing
different things: build docker images, tarballs and other things.
This creates a loose dependency between the workflows which are actually
part of the same "release workflow" which makes it difficult to spot
when one or other dependent workflow fails because the dependency is
indirect through the tagging mechanism.
This PR switches to a more direct approach using [workflow
calls](https://docs.github.com/en/actions/using-workflows/reusing-workflows).
This will create a graph as shown in the following graph:
![](https://docs.github.com/assets/cb-34427/mw-1440/images/help/actions/reusable-workflows-ci-cd.webp)
making it easier to track and identify any problem.
The "drawback" of this approach is that previously we could trigger all
dependent workflows at once by creating a tag matching the expected
pattern without manually triggering a new release. This limitation can
be overcome by adding a manual workflow_dispatch to the workflows using
the tag trigger.
[![Mend
Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [actions/setup-node](https://togithub.com/actions/setup-node) | action
| major | `v3` -> `v4` |
---
### Release Notes
<details>
<summary>actions/setup-node (actions/setup-node)</summary>
### [`v4`](https://togithub.com/actions/setup-node/compare/v3...v4)
[Compare
Source](https://togithub.com/actions/setup-node/compare/v3...v4)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "after 7pm every weekday,before 5am
every weekday" in timezone Europe/Madrid, Automerge - At any time (no
schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/Unleash/unleash).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4xMjcuMCIsInVwZGF0ZWRJblZlciI6IjM3LjEyNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Add more details about the how the version should be formatted.
When trying to run this workflow, I'm always very unsure whether the
version should be prepended with a `v` or not. This should be clearly
stated in the description. If it doesn't matter, that should also be
stated explicitly.
Updated the texts after talking to @chriswk and making a release.
## About the changes
This generates the changelog in the branch taking into account latest
release (it's conditional to wether the release ends with .0 or not)