Gitorii
Codi

Docs

CI and releases

Four commands cover the work that lives next to your history rather than inside it: CI runs, the jobs inside them, binary registries and release pages. All four detect the platform from the remote, use that platform's token, and accept --remote to target one backend of a mirrored repository.

torii pipeline list a whole CI run --pipeline torii job list the steps inside it torii job log <id> --tail 50 torii job artifacts <id> torii release list torii package list notes and assets · the binary registry --remote NAME picks which platform of a mirrored repository answers · each has its own token

Pipelines

torii pipeline list                              # this branch's recent runs
torii pipeline list --status failed --limit 50
torii pipeline cancel <id>
torii pipeline retry <id>
torii pipeline delete <id>
torii pipeline delete --status failed --older-than 7d --yes

--status takes success, failed, running, canceled or pending. A GitLab pipeline and a GitHub Actions workflow run are the same object here.

Jobs

torii job list --pipeline 1234 [--status failed]
torii job log <id> [--tail 50]
torii job retry <id>                  # GitLab
torii job cancel <id>                 # GitLab
torii job artifacts <id> -o out.zip   # GitLab
torii job erase <id>                  # GitLab

GitHub Actions scopes retry, cancel and artifacts to the workflow run rather than the job, so those subcommands return an error naming the equivalent torii pipeline operation instead of failing silently.

Packages and releases

torii package list [--type generic] [--name gitorii]
torii package files <package-id>
torii package delete --version v0.13.0 --yes
torii package delete --older-than 90d --yes

torii release list
torii release show v0.13.0
torii release edit v0.13.0 --name "New title"
torii release edit v0.13.0 --notes notes.md
torii release edit v0.13.0 --notes -          # from stdin
torii release delete v0.13.0 --yes            # the tag survives

Packages are GitLab's Package Registry; GitHub distributes binaries as release assets, which torii release covers on both.

Runners

torii runner register
torii runner spawn --docker      # bring up a self-hosted GitLab Runner container
torii runner exec <job>          # run a job locally, without pushing

runner exec is the one that saves an afternoon: it runs the job from your CI configuration against your working tree, so a broken pipeline step is debugged locally rather than through a queue of one-line commits.

Everything from the TUI

The same four surfaces are the platform view in torii tui, with drill-down from a pipeline into its jobs and into a job's log.