Gitea переехал с path-prefix (xn--90adajar8af4h.xn--p1ai/git/) на
выделенный сабдомен (git.xn--90adajar8af4h.xn--p1ai). Старый URL теперь
отдаёт чужое приложение и для git мёртв.
- package.json: publish.url (канал авто-апдейта) -> новый хост
- scripts/release.ps1, upload-release-assets.ps1: $giteaHost (API + release URL)
- README, CHANGELOG, RELEASING.md, CLAUDE.md: ссылки на репозиторий/релизы
Прим.: уже установленные копии (<=0.5.8) запекли старый URL в бинарник —
их авто-апдейт нужно мигрировать отдельно (bridge-теги), правкой конфига
это ретроактивно не лечится.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Upload script:
- Retry curl on transient network failures (504, schannel TLS abrupt
close): up to 4 retries with 15s/45s/2m/5m backoff. Before each retry,
list the release assets server-side — Gitea sometimes commits the
body but times out the response, so the file may already be there at
the expected size (skip retry). If present at wrong size (partial),
delete before re-uploading. ASCII-only (PS5.1 reads files in CP1251
without BOM).
Docs:
- README: bump release/test badges to v0.5.1 / 51 tests; mention silent
retry in the auto-update feature line.
- RELEASING: rewrite around the new update-channel architecture, bridge
tags, and dropped Gitea Actions workflows.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Gitea/nginx intermittently returns 504 on large multipart uploads even
when curl successfully streamed the body. Add up to 4 retries with
exponential backoff (15s/45s/2m/5m). Before each retry, check whether
the asset is actually present server-side at the expected size — Gitea
sometimes accepts the body but times out the response, so the file is
already there.
Also drop .gitea/workflows/* — we use release.ps1 locally and Gitea
Actions runners are not configured, so every push was leaving queued/
failed workflow runs in the Actions tab.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The auto-update system used a per-version publish URL
(releases/download/v${version}), so each installed build only ever
checked its own release page for new versions. To deliver an update we
had to manually copy the new manifest into every old release — easy to
forget, and any half-uploaded state showed users red "check failed"
banners.
Architectural fix:
- New rolling 'update-channel' Gitea release. publish.url is now a
fixed path (.../releases/download/update-channel) that never moves.
- release.ps1 uploads each new build to three places:
1. vX.Y.Z (historical archive + changelog)
2. update-channel (what every client polls)
3. -BridgeTags (transition: also fill in old releases so users
still on those versions can find the new build)
- upload-release-assets.ps1 gains -AssetVersion to upload version-X.Y.Z
artifacts into a non-version tag (channel/bridge).
Resilience fixes for the updater itself:
- Hourly checks and the boot check now run in SILENT mode: network
errors don't promote to a red error state, they're logged and
retried on the next tick. Only user-initiated "Check now" surfaces
errors. This prevents the cascade of "Ошибка проверки" cards on
flaky networks or partial uploads.
- Boot check retries up to 3 times (30s/2m/5m backoff) before giving
up until the hourly tick.
- Track lastCheckedAt; "Up to date" subtitle now shows "checked Nm ago".
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Скрипт догружает уже собранные NSIS-артефакты (.exe, .blockmap,
latest.yml) в существующий Gitea release. Создаёт release если его
нет, удаляет одноимённые активы перед перезаписью.
Используется когда:
- release.ps1 успел запушить тег, но упал на загрузке
- релиз делался руками без артефактов
- нужно перезалить артефакты после пересборки
Большие файлы (>50MB) грузятся через curl.exe, потому что
Invoke-RestMethod в PS 5.1 разрывает соединение на multipart upload
80+MB. Прогресс печатается отдельно для каждого файла.
Использован для загрузки v0.3.0 артефактов.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
