https://github.com/voideditor/void-updates-server
Endpoint Void uses to check for updates.
https://github.com/voideditor/void-updates-server
Last synced: over 1 year ago
JSON representation
Endpoint Void uses to check for updates.
- Host: GitHub
- URL: https://github.com/voideditor/void-updates-server
- Owner: voideditor
- License: apache-2.0
- Created: 2025-01-29T05:55:59.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2025-04-16T19:09:52.000Z (over 1 year ago)
- Last Synced: 2025-05-07T12:56:02.899Z (over 1 year ago)
- Language: Shell
- Homepage: https://updates.voideditor.dev
- Size: 144 KB
- Stars: 9
- Watchers: 2
- Forks: 5
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
This is an endpoint that Void pings to check for updates and get a downloadURL. Super simple, entry point is here: https://github.com/voideditor/void-updates-server/blob/main/app/%5B...route%5D/route.ts
Eventually we should get rid of this in favor of void-builder.
## Overview
Whenever we want to create a new release of Void, we run `./mac.sh`. This generates a folder called VoidSign-arm64 with these contents:
1. `Void.app` (inside a `.zip` file)
2. `hash.json`
3. `Void.dmg`
- `Void.app` is the raw file that actually runs Void. Updates work by simply swapping in a new version of this.
- `hash.json` are hashes to make sure `Void.app` was not corrupted on download.
- `Void.dmg` is the installer for Void. Just a wrapper around `Void.app`, not used in updating.
## Updating Flow
Here's how updating is intended to work. Reference [`abstractUpdateService.ts`](https://github.com/voideditor/void/blob/c1123f2cfd570e744e0e867f5f53d0c108c32c97/src/vs/platform/update/electron-main/abstractUpdateService.ts#L18).
First, Void pings the update server (this repo) which lives on `https://updates.voideditor.dev/api/update//stable/`. (product is something like darwin-arm64, and commit is the commit hash, e.g. abcdefg123).
Here's what happens next:
```
Void on Desktop update server
-----check for update------>
- compare latest commit hash with user's commit hash
- if not equal, respond with a JSON
JSON <---------respond----------
```
the returned JSON is of type:
```ts
{
"url": "https://github.com/voideditor/void/releases/v1.0.0/Void-RawApp-darwin-arm64.zip", // where to go to get the `Void.app` `.zip` file
// ---------- this is from the latest hash.json to validate the above url ----------
"sha256hash": "7bfd6874c1608149d9cecaab51e5cd5fca715ca0f7c3d34918017f0cbdadd81b", // sha256 hash
"hash": "033bd94b1168d7e4f0d644c3c95e35bf1ce6bfab", // sha1 hash
"timestamp": 1241241411738132963, // unix timestamp (not really important)
"version": "abcdefg123", // latest commit hash
// ---------------------------------------------------------------------------------
// this doesn't really matter
"productVersion": "1.9.4",
}
```
Right now, running everything described above, we get an error like "signature could not be verified" once `Void.app.zip` is downloaded. It's not clear if this is a hash signature issue, a mac codesigning issue, or something else.
So we're not using the built-in auto-updater right now, and instead we're prompting the user to update manually (not ideal).
## Todos
- We might want to turn Void into a monorepo so we can share version number and commit across the update server, website, and desktop app.
## New release of Void
To do a new Void release (should only be done by maintainers):
1. Run ./mac.sh on Mac, ./windows.sh on windows, and _ on linux (still being added).
2. Upload all files to the GitHub release (for now, typically we don't change the tag).
3. Update commit number and version number on the `void-updates-server` after all releases have been uploaded, to start informing users of an update.
4. If we changed the GitHub release tag, make sure to change the download URLs on `void-website` too.
5. Update the changelog on `void-website`.
## GitHub release version number
- For now, we're just sticking with a GitHub release the major version number so we don't have to make a lot of changes every time we update. For example, GitHub releases will be on v1.0.0 even if we're on 1.0.1, 1.1.0, etc.
- We're not moving the v1.0.0 tag to the newer commit during releases, because we want the next tag to auto-populate all the changes since the last tag.