Description:
The release-gui.yml uses on: workflow_run. This trigger has some known limitations:
- Context/Permissions:
workflow_run always runs in the context of the default branch. If you are testing a release on a feature branch, it might not behave as expected.
- Security: It can be tricky to pass data securely between the two workflows.
- Manual Trigger Redundancy: The
check-version job re-implements logic to check if a release exists, which adds overhead and complexity.
Suggested Solution:
- Use
workflow_call (Reusable Workflows) to chain the CLI and GUI releases together.
- Alternatively, trigger both workflows simultaneously when a new tag
v* is pushed. This ensures both use the exact same commit SHA and simplifies the logic significantly.
Description:
The
release-gui.ymluseson: workflow_run. This trigger has some known limitations:workflow_runalways runs in the context of the default branch. If you are testing a release on a feature branch, it might not behave as expected.check-versionjob re-implements logic to check if a release exists, which adds overhead and complexity.Suggested Solution:
workflow_call(Reusable Workflows) to chain the CLI and GUI releases together.v*is pushed. This ensures both use the exact same commit SHA and simplifies the logic significantly.