Every release, documented.
Release notes are pulled directly from GitLab and may appear in English.
todo.sr.ht): list / create / close / comment viabuilds.sr.ht): list / cancel + log work. Otherretry / job_retry return an error pointing at the web UI —delete returns an error — builds keep retention-policy-managedjob_artifacts_download and job_erase return clear errors.cherry-pick (and --continue)revertmerge (the merge commit itself)history reauthor (rewritten commits)history rewrite (date rewrites)history remove-file (filter-branch replacement)user.name / user.email from --local config are now actuallygit.sign_commits = truesrc/gpg.rs shells out to the system gpg binarycommit_inner helper in core.rs routes both torii save andcherry-pick, revert, merge,gpg (or gpg2) on PATH. Clear error if missing.user.signingkey and commit.gpgsign config aliases.** They mapsrc/http.rs module withtorii auth set codeberg <token>** (or gitea / forgejo) allplatform entry in the sidebar1 Pipelines, 2 Jobs, 3 Releases, 4 Packagesr opens a centred popup** to switch the remoteCtrl-R reloads** the active sub-tab.add mirror was unreachable.** The "add mirror" entry only--remote NAME on every platform-management command.** The four CLI surfaces added in 0.7.7 and 0.7.10 (torii pipeline, torii job, torii package, torii release) all auto-detected the platform from the origin remote URL. That works when there's only one platform — most projects — but breaks the multi-platform case where a repo is mirrored across e.g. GitLab (origin) and GitHub (github-paskidev). Each backend has its own releases, its own pipeline runs, its own packages; both should be reachable from the CLI.torii job {list, log, retry, cancel, artifacts, erase} — individual CI job control.** Sibling to torii pipeline (which manages whole pipelines / workflow runs); torii job drills into the jobs inside a pipeline.torii job list --pipeline <id> [--status STATUS] — enumerate jobs of one pipeline, optionally filtered. Output is a one-line-per-job table with icon, raw status, name, stage, duration. The status filter is normalized (success | failed | running | canceled | pending) and applied client-side after the fetch so the same flag means the same thing on both backends.torii job log <id> [--tail N] — **the killer feature.** Fetches the raw trace and prints it. With --tail N only the last N lines are printed, which is the common case during failure post-mortems. Replaces the previous "open the UI, click into the job, scroll to the bottom of the log" round-trip. During the v0.7.9 saga this would have saved ~30 minutes of curl /jobs/<id>/trace | tail -20 repetition.torii job retry <id> — GitLab only. Re-runs a single failed job without re-running the entire pipeline (which on a 25-minute matrix is the difference between "5 min retry" and "25 min retry"). GitHub Actions doesn't support per-job retry (only /runs/:run_id/rerun-failed-jobs at the run level); the GitHub backend returns a hint pointing at torii pipeline retry <run-id>.torii job cancel <id> — GitLab only, same asymmetry as retry.torii job artifacts <id> [-o <path>] — GitLab only. Downloads the per-job artifacts archive to disk. On GitHub artifacts are run-scoped, not job-scoped; the backend returns an error explaining this. Default output path is ./<job-id>-artifacts.zip.torii job erase <id> [--yes] — GitLab only. Clears a job's log + artifacts but keeps the job entry visible in the UI (useful for storage cleanup when you want history). GitHub returns unsupported.src/pipeline.rs — extends the existing PipelineClient trait rather than adding a parallel JobClient trait, since jobs are conceptually under pipelines and share the same auth + base URL. Asymmetric capabilities are handled by Err returns with self-explanatory hints (no silent fallback, no panics on unsupported ops).torii package {list, files, delete} — GitLab Package Registry management.** GitLab's Generic Package Registry stores release binaries between runs (gitorii's release pipeline uploads three cross-compiled binaries per tag — linux x86_64, linux aarch64, windows x86_64). Without cleanup, this accumulates against the namespace's 5 GB free-tier storage cap.torii package list [--type TYPE] [--name SUBSTR] [--limit N] — enumerate packages. --type generic is the gitorii case; the surface also supports the other types GitLab exposes (npm, maven, conan, pypi, composer, nuget, helm) without code changes — the parser is type-agnostic.torii package files <package-id> — list files inside a package with their sizes (in MB). Useful for understanding what's stored before deleting.torii package delete <id> | --version vX.Y.Z | --older-than 90d --yes — three modes: single-id, by-exact-version, by-age. The filter modes are mutually exclusive with the explicit id (clap-enforced). Batch mode previews up to 10 entries before confirmation, then iterates one-by-one with per-id success/failure reporting — same pattern as torii pipeline delete.src/package.rs (~280 lines, follows the pipeline.rs shape). GitLab-only on purpose: GitHub's binary-distribution model is Release Assets attached to Releases, which is torii release's scope below.torii release {list, show, edit, delete} — Release page management.** Both backends.torii release list [--limit N] — recent releases. One-line-per-release.torii release show <tag> — full details (description body, web URL, created date). Useful for previewing what's published before editing or for grabbing the URL to paste somewhere.torii release edit <tag> [--name X] [--notes notes.md | -] — patch the release name and/or description without re-tagging or re-running CI. --notes accepts either a path to a markdown file or - for stdin (so you can pipe in dynamically-generated notes). Fixes the workflow of "oops I had a typo in the CHANGELOG section that got copied to the GitLab Release" without forcing a re-release.torii release delete <tag> [--yes] — removes the Release entity (the underlying tag stays — use torii tag delete <tag> if you also want the tag gone). Useful when CI auto-created a release with garbage in the description because of an interrupted run.src/release.rs (~340 lines).void-torii with tag gitorii, shell executor, Arch host) was abandoned after rustc 1.94.0 reproducibly SIGSEGV'd on this host even in trivial crates like libc, idna, fiat-crypto, num-traits — independent of RUST_MIN_STACK (tested up to 512 MB), CARGO_BUILD_JOBS=1, or LimitSTACK=infinity via systemd. The crash also reproduced in a standalone cargo build outside gitlab-runner, confirming it's a rustc-1.94/glibc/kernel interaction on that specific Arch host — unrelated to gitorii or the YAML..gitlab-ci.yml: removed default: tags: [gitorii] so jobs go to saas-linux-small-amd64 shared runners. The russh / rsa-rc / sec1 generic-tree stack pressure is covered by the RUST_MIN_STACK="33554432" already in the YAML's variables: block — shared runners satisfy the request without kernel-cap issues.RUST_MIN_STACK=536870912, CARGO_BUILD_JOBS=1) introduced during the self-hosted debug iteration; they're no longer needed.torii sync, torii fetch, torii push tags now authenticate with HTTPS token (gitlab_token, github_token, etc.) — previously only SSH was supported, causing auth failures on HTTPS remotesvX.Y.Z), suppressing unwanted branch pipelinestorii sync --force and torii sync --push now also sync replica mirrors automaticallyslaves variable references to replicas in mirror outputPRIMARY instead of MASTERtorii sync now automatically pushes to all configured replica mirrors after syncing with origin — no need to run torii mirror sync manuallymut on index variable in rebase looprepo_path variable in show commandFull history on GitLab