learnharness/docs/gitea-release.md

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.

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:

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:

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:

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:

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.