# Gitea releases for this fork

The release destination is
https://server2.sorokin-oleg-edu.xyz/replicated/learnharness.
Version **0.4.0 targets Linux x64**. Windows is deferred until a native Windows
builder is available. The upstream GitHub workflow and three-platform packaging
configuration remain available as reference in `.github/workflows/release.yml`
and `electron-builder.yml`.

Official fork packages use `electron-builder.gitea.yml`, which inherits the
upstream packaging and replaces its update origin with:

```
https://server2.sorokin-oleg-edu.xyz/replicated/learnharness/releases/download/latest
```

Gitea's `latest` alias resolves the most recent published, non-prerelease release.
Drafts do not become updates. The repository and published downloads must be
public; no API credential is embedded in the application.

## Preparing Linux packages

Use Node **26**, matching upstream's release gates. Build from a clean checkout
of the intended release commit. Keep `.env*`, local keys, and application data out
of the build directory. Next can copy loaded environment files after tracing;
`build-server.mjs` refuses a payload containing them. A clean worktree avoids
loading these files in the first place.

```sh
npm ci
npm run typecheck
npm test
npm run lint
ELECTRON_RUN_AS_NODE=1 npx electron --import tsx --test tests/pdf-native-render.test.ts tests/pdf-ops.test.ts tests/svg-native-render.test.ts tests/browser-service.test.ts
npm run desktop:release:linux
```

The release script builds the standalone server, initializes providers offline,
curates the payload, boots it under Electron's bundled Node, packages AppImage
and Debian installers, creates SHA-256 checksums, and verifies update metadata
against the actual installer bytes.

Run the packaged-runtime gates too:

```sh
node scripts/smoke-provider-runtime.mjs --standalone dist/linux-unpacked/resources/server/standalone
node scripts/smoke-provider-runtime.mjs --standalone dist/linux-unpacked/resources/server/standalone --runtime dist/linux-unpacked/learnharness
xvfb-run -a node scripts/smoke-demo-runtime.mjs --standalone dist/linux-unpacked/resources/server/standalone --runtime dist/linux-unpacked/learnharness --browser
```

The Linux 0.4.0 release has exactly four attachments:

- `LearnHarness-0.4.0-x86_64.AppImage`
- `LearnHarness-0.4.0-amd64.deb`
- `latest-linux.yml`
- `SHA256SUMS`

## Preparing the Gitea draft

Commit and push the release source, then push its exact annotated tag:

```sh
git tag -a v0.4.0 -m 'LearnHarness 0.4.0'
git push gitea main v0.4.0
```

Supply `GITEA_TOKEN` only to the upload command. A token file may remain outside
the clean build checkout:

```sh
node --env-file=/path/to/private/release.env scripts/gitea-release.mjs upload dist
```

The tool requires the tag to exist in Gitea, creates or reuses one draft at that
tag, uploads missing assets, and downloads every attachment to verify its actual
SHA-256 against the local verified build. Existing mismatched attachments and
published releases are refused. It never publishes or changes repository
visibility. Release notes come from `docs/release-0.4.0.md`.

A separate verification can be repeated without changing the draft:

```sh
node --env-file=/path/to/private/release.env scripts/gitea-release.mjs verify-remote dist
```

Review the verified draft before publication. Only after publication will the
public `latest` feed and in-app automatic updates expose this version.

## Gitea Actions

`.gitea/workflows/release.yml` provides the same Linux gates through a manual
workflow with an existing release tag as input. It requires a native Linux x64
runner labeled `ubuntu-24.04`, the label used by upstream's Linux release job,
plus the native Electron dependencies and `xvfb-run`. There were no runners
registered when 0.4.0 was prepared, so its packages are built locally. A tag push
does not queue a job that cannot run.

The workflow uses the repository's ephemeral `GITEA_TOKEN` with release-write
permission only in the final upload step. It checks out the requested tag without
persisting credentials and leaves the result as a verified draft. Public pull
requests cannot trigger this publishing workflow. Add Windows only with a native
Windows build and its corresponding smoke checks; do not substitute a Linux
standalone payload into a Windows installer.