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/github-script](https://togithub.com/actions/github-script) |
action | major | `v6` -> `v7` |
---
### Release Notes
<details>
<summary>actions/github-script (actions/github-script)</summary>
### [`v7`](https://togithub.com/actions/github-script/compare/v6...v7)
[Compare
Source](https://togithub.com/actions/github-script/compare/v6...v7)
</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:eyJjcmVhdGVkSW5WZXIiOiIzNy44MS4zIiwidXBkYXRlZEluVmVyIjoiMzcuODEuMyIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
## About the changes
Avoids code injection via the committer name or email
Also removes pushing to s3 on `main` folder as it's not used and we're
already pushing to `commits` folder
## About the changes
Previous PR https://github.com/Unleash/unleash/pull/3871 we were
supposed to change this for PRs but the change was made on
`release.yaml` file. This fixes the issue
## About the changes
Delay static asset generation to speed up the CI/CD pipeline.
Next, we should add a validation step before deployment to validate that
the static assets were properly published