Siete clientes, y lo que cada uno se niega a fingir

Mayo añadió cuatro plataformas en diez días: Codeberg y la familia Gitea en 0.7.13, Sourcehut en 0.7.15, Radicle en 0.7.16, Bitbucket Cloud en 0.7.17 y Azure DevOps en 0.7.18. Eso hace siete clientes sobre nueve hosts, y conviene escribir cómo funciona el enrutado antes de que la lista crezca más.

La URL decide

Tú nunca nombras la plataforma. torii pr list mira el remoto con el que va a hablar, casa el host y despacha al cliente correspondiente. dev.azure.com y el antiguo *.visualstudio.com significan Azure; rad:// significa Radicle; git.sr.ht significa Sourcehut.

Las instalaciones autoalojadas rompen eso, porque el host es el que tú le hayas puesto. Desde 0.8.0, ~/.config/torii/platforms.toml es donde lo declaras: un host, un tipo de plataforma, y la detección lo enruta como a cualquier otro.

Un cliente, tres hosts

Gitea, Codeberg y Forgejo comparten un solo cliente, porque Codeberg es Gitea y Forgejo es un fork que conservó la API. Tres nombres en torii auth, una implementación debajo, y resolve_gitea_token prueba los tres en orden. Por eso el sitio cita siete clientes y nueve hosts como cifras distintas: lo son.

Dónde se para la abstracción

Cada cliente responde a las mismas cinco preguntas —pull requests, incidencias, pipelines, releases, paquetes— y aquí sería fácil mentir. Bitbucket Cloud no tiene objeto de release ni registro de paquetes. Radicle no tiene CI, ni página de release, e identifica sus patches por hash de contenido en vez de por el id numérico que toman los traits. Sourcehut acepta parches por correo, no como merge request.

Ninguna de esas devuelve una lista vacía. Una lista vacía significa «no hay ninguno», y la verdad es «esta plataforma no tiene eso», así que devuelven un error que lo dice y señala qué hace la plataforma en su lugar. Una herramienta que devuelve nada en silencio te enseña a desconfiar de todos los resultados vacíos que te dé en el futuro.

Repositorios replicados

En cuanto un repositorio vive en más de una plataforma, «la plataforma» es ambiguo: cada backend tiene sus pipelines, sus releases y sus paquetes. --remote NAME elige uno:

torii pipeline list --remote origin
torii release edit v0.13.0 --notes new.md --remote github-paskidev

Cada uno tiene también su token, así que operar sobre los dos significa tener los dos configurados. La opción es global dentro de su comando, lo que quiere decir que torii pipeline --remote NAME list y torii pipeline list --remote NAME son la misma frase con las palabras en otro orden, y las dos funcionan.

Lo que se debe todavía

La visibilidad del repositorio —pasar de público a privado— está cableada solo para GitHub y GitLab. La familia Gitea y Bitbucket exponen la misma llamada y aún no están conectadas; Azure pone la visibilidad en el proyecto y no en el repositorio, así que ahí la respuesta honesta es un error que te manda a los ajustes del proyecto. Está en el roadmap, y hasta que llegue la tabla de la página de comparativa lo dice.