Update README.md

2026-03-11 11:38:29 +00:00
parent 22f583e6b3
commit c8fd26e937
1 changed files with 0 additions and 94 deletions
--- a/README.md
+++ b/README.md
@@ -26,100 +26,6 @@ Server files:
 - `server/data/variables.json` holds `klipyApiKey`
 - `server/data/variables.json` also holds `releaseManifestUrl` for desktop auto updates

-## Desktop auto updates
-
-The packaged Electron app now reads a hosted release manifest from the active server's `/api/health` response.
-
-Release flow:
-
-1. Build the desktop packages with `npm run electron:build` or the platform-specific Electron Builder commands.
-2. Upload one version folder that contains the generated `latest.yml`, `latest-mac.yml`, `latest-linux.yml`, and the matching installers/artifacts.
-3. Generate or update the hosted manifest JSON with:
-
-	 `npm run release:manifest -- --feed-url https://your-cdn.example.com/metoyou/1.2.3`
-
-4. Set `releaseManifestUrl` in `server/data/variables.json` to the hosted manifest JSON URL.
-
-### GitHub / Gitea release assets
-
-If you publish desktop builds as release assets, use the release download URL as the manifest `feedUrl`.
-
-Examples:
-
- GitHub tag `v1.2.3`:
-
-	 `https://github.com/OWNER/REPO/releases/download/v1.2.3`
-
- Gitea tag `v1.2.3`:
-
-	 `https://gitea.example.com/OWNER/REPO/releases/download/v1.2.3`
-
-That release must include these assets with their normal Electron Builder names:
-
- `latest.yml`
- `latest-mac.yml`
- `latest-linux.yml`
- Windows installer assets (`.exe`, `.blockmap`)
- macOS assets (`.dmg`, `.zip`)
- Linux assets (`.AppImage`, `.deb`)
-
-You should also upload `release-manifest.json` as a release asset.
-
-For a stable manifest URL, point the server at the latest-release asset URL:
-
- GitHub:
-
-	 `https://github.com/OWNER/REPO/releases/latest/download/release-manifest.json`
-
- Gitea: use the equivalent latest-release asset URL if your instance supports it, otherwise publish `release-manifest.json` at a separate stable URL.
-
-If you want the in-app "Specific version" option to list older releases too, keep one cumulative manifest and merge the previous file when generating the next one:
-
-	 `npm run release:manifest -- --existing ./release-manifest.json --feed-url https://github.com/OWNER/REPO/releases/download/v1.2.3 --version 1.2.3`
-
-The manifest format is:
-
-```json
-{
-	"schemaVersion": 1,
-	"generatedAt": "2026-03-10T12:00:00.000Z",
-	"minimumServerVersion": "1.0.0",
-	"pollIntervalMinutes": 30,
-	"versions": [
-		{
-			"version": "1.2.3",
-			"feedUrl": "https://your-cdn.example.com/metoyou/1.2.3",
-			"publishedAt": "2026-03-10T12:00:00.000Z"
-		}
-	]
-}
-```
-
-`feedUrl` must point to a directory that contains the Electron Builder update descriptors for Windows, macOS, and Linux.
-
-### Automated Gitea release queue
-
-The Gitea workflows in `.gitea/workflows/release-draft.yml` and `.gitea/workflows/publish-draft-release.yml` keep the existing desktop auto-update flow intact.
-
-On every push to `main` or `master`, the release workflow:
-
-1. Computes a semver release version from the current `package.json` major/minor version and the workflow run number.
-2. Builds the Linux and Windows Electron packages.
-3. Builds standalone server executables for Linux and Windows.
-4. Downloads the latest published `release-manifest.json`, merges the new release feed URL, and uploads the updated manifest to the draft release.
-5. Uploads the desktop installers, update descriptors, server executables, and `release-manifest.json` to the matching Gitea release page.
-
-The draft release uses the standard Gitea download path as its `feedUrl`:
-
-	 `https://YOUR_GITEA_HOST/OWNER/REPO/releases/download/vX.Y.Z`
-
-That means the current desktop auto-updater keeps working without any client-side changes once the draft release is approved and published.
-
-To enable the workflow:
-
- Add a repository secret named `GITEA_RELEASE_TOKEN` with permission to create releases and upload release assets.
- Make sure your Gitea runner labels match the workflow `runs-on` values (`linux` and `windows`).
- After the draft release is reviewed, publish it either from the Gitea release page or by running the `Publish Draft Release` workflow with the queued release tag.

 ## Main commands