archy/docs/release-process.md

112 lines
2.6 KiB
Markdown
Raw Normal View History

# Archipelago Release Process
## Overview
Archipelago uses a JSON-based release manifest for the auto-update system. The backend checks `UPDATE_MANIFEST_URL` periodically (based on user's schedule setting) and compares versions.
## Manifest Format
The manifest is a single JSON file at:
```
https://raw.githubusercontent.com/archipelago-os/releases/main/manifest.json
```
```json
{
"version": "0.2.0",
"release_date": "2026-04-01",
"changelog": [
"Added automatic update scheduling",
"Improved backup encryption"
],
"components": [
{
"name": "archipelago",
"current_version": "0.1.0",
"new_version": "0.2.0",
"download_url": "https://github.com/archipelago-os/releases/releases/download/v0.2.0/archipelago",
"sha256": "abc123...",
"size_bytes": 15000000
}
]
}
```
## Release Steps
### 1. Build Release Artifacts
On the build server (192.168.1.228):
```bash
# Build backend (release mode)
cd ~/archy/core
cargo build --release -p archipelago
# Build frontend
cd ~/archy/neode-ui
npm run build
```
### 2. Generate Manifest
```bash
./scripts/create-release-manifest.sh \
--version 0.2.0 \
--date 2026-04-01
```
This auto-detects the backend binary and frontend archive, computes SHA256 hashes, and writes `manifest.json`.
### 3. Upload Artifacts
Upload the backend binary and frontend archive to GitHub Releases:
```bash
gh release create v0.2.0 \
core/target/release/archipelago \
/tmp/archipelago-frontend-0.2.0.tar.gz \
--title "v0.2.0" \
--notes "See CHANGELOG.md for details"
```
### 4. Publish Manifest
Push the generated `manifest.json` to the releases repo:
```bash
# In the archipelago-os/releases repo
cp manifest.json .
git add manifest.json
git commit -m "Release v0.2.0"
git push
```
### 5. Tag the Source
```bash
git tag v0.2.0
git push --tags
```
## Update Schedules
Users can configure how updates are handled:
| Schedule | Behavior |
|----------|----------|
| **Manual** | Never checks automatically. User must click "Check for Updates" |
| **Daily Check** (default) | Checks once per day. Notifies user, who decides when to install |
| **Auto-Apply** | Checks daily. Downloads and applies at 3 AM, restarts service |
## Rollback
If an update causes issues, users can rollback from the System Update page. The previous binary is backed up to `{data_dir}/update-backup/` before applying.
## Security
- All downloads are verified against SHA256 hashes in the manifest
- The manifest itself is fetched over HTTPS from a known URL
- Binary replacement requires service restart (handled by systemd)
- Rollback is always available after an update