Update README.md
This commit is contained in:
94
README.md
94
README.md
@@ -26,100 +26,6 @@ Server files:
|
|||||||
- `server/data/variables.json` holds `klipyApiKey`
|
- `server/data/variables.json` holds `klipyApiKey`
|
||||||
- `server/data/variables.json` also holds `releaseManifestUrl` for desktop auto updates
|
- `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
|
## Main commands
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user