Старый pubkey в конфиге был без парного приватного ключа — обновления
никогда не смогли бы пройти проверку подписи. Сгенерирована новая пара,
приватная часть — в secrets.TAURI_SIGNING_PRIVATE_KEY(_PASSWORD) этого
репозитория.
tauri-apps/tauri-action жёстко ходит в api.github.com для создания релиза и
загрузки апдейтер-артефактов — не настраиваемый эндпоинт, для Gitea не
годится ни при какой замене секретов. Вместо неё:
- scripts/gitea-publish-release.mjs — публикует релиз через прямые вызовы
Gitea Release API: собирает latest.json (формат манифеста Tauri v2
updater) из .sig-файлов подписанных бандлов, создаёт версионный релиз
(тег = версия, для истории) и пересоздаёт релиз "latest" — у Gitea нет
built-in алиаса /releases/latest/download/<file> как у GitHub, поэтому
тег "latest" удаляется и создаётся заново на каждом релизе с теми же
ассетами, чтобы URL апдейтера был стабильным. Оба релиза
удаляются-и-пересоздаются — идемпотентно к повторному прогону тега.
- .gitea/workflows/release.yml — job "build" (та же матрица платформ) вызывает
`tauri build` напрямую (подпись через TAURI_SIGNING_PRIVATE_KEY читает сам
Tauri CLI, без разницы кто его вызывает), собирает пары <файл>+.sig в
dist-bundle/ и грузит артефактом bundle-<updater_key>; job "publish"
скачивает все артефакты и вызывает скрипт выше.
- tauri.conf.json: добавлен второй updater-эндпоинт (Gitea, плейсхолдер
CHANGE_ME_GITEA_SERVER — заполнить реальным адресом) рядом с
существующим GitHub — апдейтер пробует оба по порядку.
GitHub-версия пайплайна не тронута, продолжает работать через tauri-action
как раньше. Не проверено вживую на реальном Gitea/Windows/macOS раннере —
нет доступа в этой среде.
Нужные секреты в Gitea: GITEA_SERVER_URL, GITEA_TOKEN (личный токен с
правом записи в репозиторий), плюс уже существующие
TAURI_SIGNING_PRIVATE_KEY(_PASSWORD).
nineap