mirror of
https://github.com/Unleash/unleash.git
synced 2024-10-28 19:06:12 +01:00
07354f7218
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:  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. |
||
|---|---|---|
| .. | ||
| add-to-project.yml | ||
| auto-assign-pr-author.yaml | ||
| build_coverage.yaml | ||
| build_doc_prs.yaml | ||
| build_frontend_prs.yml | ||
| build_prs_jest_report.yaml | ||
| build.yaml | ||
| check_links.yaml | ||
| codeql-analysis.yml | ||
| docker_publish.yaml | ||
| e2e.frontend.yaml | ||
| flag-no-response.yaml | ||
| generate-docs.yaml | ||
| gradual-strict-null-checks.yml | ||
| notify_enterprise.yaml | ||
| pr_add_test_results.yaml | ||
| publish-new-version.yaml | ||
| release_changelog.yml | ||
| release.yaml | ||
| reset_heroku.yml | ||
| update_contributors.yaml | ||
| update_version_for_version_checker.yml | ||
| validate-migrations.yaml | ||
