trigger-desktop.yml was pushing a submodule bump commit (which fires
release.yml via the push event) AND then explicitly dispatching
release.yml via the API, causing every cinny push to produce two
back-to-back desktop builds. Drop the dispatch step; the push alone
is sufficient.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Replace the contents-API workaround with a direct workflow_dispatch call
using ACTIONS_TOKEN (which has Actions:write scope). Cascade prevention
in Gitea blocked all previous push-based approaches.
The submodule bump is kept for correct SHA tracking in git history.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Gitea suppresses workflow events from Actions runner pushes to prevent
infinite loops, so the submodule bump commit was never firing release.yml.
Add a second step that writes .cinny-version via the REST contents API —
that creates a user-attributed commit Gitea does not suppress.
The submodule bump is kept for correct SHA tracking; the API commit is
the actual trigger.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
workflow_dispatch API requires Actions:write token scope which
RELEASE_TOKEN doesn't have. Worse, even a successful dispatch would
check out the old pinned submodule SHA, not the new cinny commit.
New approach: clone cinny-desktop, point the cinny submodule at the
current commit SHA, commit, and push. The push to cinny-desktop/main
fires release.yml naturally — no special permissions needed beyond
repo write (which RELEASE_TOKEN already has for release uploads).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
jared