ci.yml's four jobs (lint, tests, audit, gui check) still used
runs-on: ubuntu-latest. Since the Gitea runners were relabeled (see
the previous ci(release) commit), that alias now resolves only to
hostinger-runner — the single native amd64 machine release.yml routes
the x86_64 build legs to. Every CI push was piling onto that one
runner alongside the release jobs, and it could not keep up: run 73
(triggered by the previous commit) shows 'Set up job' taking 15m22s
and then every following step failing in 0s, including deterministic
ones like cargo fmt --check that have nothing to do with runner
architecture.
Pins all four ci.yml jobs to linux-arm64 (the two oracle-runner
replicas), matching the explicit-label convention release.yml already
uses, and freeing hostinger-runner to do only what it was provisioned
for.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAyr8d7HuAdUGB6aA5xmDD
Two changes to release.yml, kept together since they touch the same
jobs:
1. Drops the 'updater' job ('Build latest.json'): the desktop app no
longer reads a Tauri-updater manifest (see the previous commit), so
nothing consumes it any more. Also drops the now-unused
GUARA_TAURI_SIGNING_PRIVATE_KEY(_PASSWORD) secrets from the 'gui'
job's env and the header comment documenting them.
2. Routes the linux-x86_64 leg of the cli and gui matrices to the new
native x86_64 Gitea Actions runner (hostinger-runner, label
linux-amd64) instead of cross-compiling it from an aarch64 host
(oracle-runner/-b, label linux-arm64):
- matrix.include gets an explicit runner field per platform;
runs-on: ${{ matrix.runner }} picks it per job. windows also
pinned to linux-amd64 explicitly rather than relying on the
ubuntu-latest alias, since that alias now points at whichever
runner is tagged for it and is no longer a safe stand-in for
"the aarch64 host" (it briefly meant exactly that, then got
relabeled to the x86_64 runner — pinning explicit labels avoids
depending on that alias at all).
- The "Platform cross-linker" step (gcc-x86-64-linux-gnu) only
runs when NOT on the native amd64 runner, since a native build
needs no cross-linker.
- scripts/build-gui.sh and scripts/package-cli.sh are intentionally
left untouched: both already branch on `uname -m` and take the
simple native path when run on x86_64. The existing cross-compile
path (qemu wrappers, the ELF launcher that survives
tauri-bundler's dd patch) stays in place as a dormant fallback in
case the single amd64 runner is ever unavailable — deliberately
kept, not deleted.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAyr8d7HuAdUGB6aA5xmDD
Replaces the signed tauri-plugin-updater (latest.json manifest, minisign
key pair) with the same simple mechanism Sabiá already uses: query the
Gitea Releases API directly, download the matching platform archive,
verify its SHA-256 checksum, and swap the binary in place. The CI job
that built the old latest.json manifest is removed in the next commit,
alongside an unrelated runner-routing change to the same workflow file.
- New guara-core::update module (check/apply), ported from
sabia-core::update and adapted to Guará's own release asset naming
(guara-<tag>-<platform>.tar.gz, matching scripts/package-cli.sh).
- New Engine::update_check / Engine::update_apply, wired into the RPC
service for the browser UI.
- New CLI subcommand: "guara update" (check) and "guara update --apply"
(download, verify, replace), mirroring "sabia update".
- GUI: replaced the Tauri plugin-updater flow (download_and_install,
update-progress events, in-app restart) with a call to the new
update_check/update_apply commands. The desktop app can no longer
self-install in one click — it now points the user to the Releases
page, same as Sabiá's desktop app already does.
- Removed tauri-plugin-updater, createUpdaterArtifacts and the
updater.pubkey config, the signing-key loading in build-gui.sh, the
CI step testing the old latest.json generator, and the now-unused
make-latest-json.py/test_make_latest_json.py scripts.
- Documented the break for existing installs in CHANGELOG.md /
CHANGELOG.pt-BR.md: versions up to 1.3.2 won't find this release
automatically and need one manual download.
Trade-off accepted knowingly: SHA-256 verifies integrity against
Gitea's own API but, unlike the retired signed mechanism, does not
protect against a compromised Gitea server independently of it. This
is Lucas's own self-hosted instance, not a third-party mirror.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAyr8d7HuAdUGB6aA5xmDD
Completes the English-only standardization for code, comments, scripts
and CI templates (UI/CLI-facing strings stay bilingual pt-BR/en,
untouched). Covers the remaining crates/, apps/gui/ui/ and
apps/gui/src-tauri/ comments, .gitea/ workflow and template comments,
.githooks/ hooks, and the scripts/ source comments for the files
already renamed in a prior commit (check.sh, generate-logo.py,
install-hooks.sh).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAyr8d7HuAdUGB6aA5xmDD
The updater reads latest.json from Gitea, built by scripts/make-latest-json.py
against the Gitea API (no gh CLI). Release workflow builds the Linux CLI and
the Linux+Windows desktop app, signs the updater artifacts and attaches
everything to the release.
Needs the repo secrets TAURI_SIGNING_PRIVATE_KEY and
TAURI_SIGNING_PRIVATE_KEY_PASSWORD, which I could not set (secret-store writes
are reserved for the user) - set them from ~/.tauri/guara-updater.key and
.pass before pushing a tag.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Notes come from the matching CHANGELOG.md section. The macOS and Windows
binaries the old release workflow built need runners this Gitea does not have.
The CI also ignores .wolf, .claude and the release files.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Linux-only runner, so the Windows and macOS legs and GitHub's audit action are
gone. The Rust toolchain, cargo registry and target directories live on the
runner's persistent toolcache volume. release.yml stays under .github and is
not run by Gitea.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
