Set clients, i el que cadascun es nega a fingir

El maig va afegir quatre plataformes en deu dies: Codeberg i la família Gitea a 0.7.13, Sourcehut a 0.7.15, Radicle a 0.7.16, Bitbucket Cloud a 0.7.17 i Azure DevOps a 0.7.18. Això fa set clients sobre nou hosts, i convé escriure com funciona l'encaminament abans que la llista creixi més.

La URL decideix

Tu no anomenes mai la plataforma. torii pr list mira el remot amb qui parlarà, casa el host i despatxa al client corresponent. dev.azure.com i l'antic *.visualstudio.com volen dir Azure; rad:// vol dir Radicle; git.sr.ht vol dir Sourcehut.

Les instal·lacions autoallotjades trenquen això, perquè el host és el que tu li hagis posat. Des de 0.8.0, ~/.config/torii/platforms.toml és on ho declares: un host, un tipus de plataforma, i la detecció l'encamina com qualsevol altre.

Un client, tres hosts

Gitea, Codeberg i Forgejo comparteixen un sol client, perquè Codeberg és Gitea i Forgejo és un fork que va conservar l'API. Tres noms a torii auth, una implementació a sota, i resolve_gitea_token prova els tres per ordre. Per això el lloc cita set clients i nou hosts com a xifres diferents: ho són.

On s'atura l'abstracció

Cada client respon les mateixes cinc preguntes —pull requests, incidències, pipelines, releases, paquets— i aquí seria fàcil mentir. Bitbucket Cloud no té objecte de release ni registre de paquets. Radicle no té CI, ni pàgina de release, i identifica els seus patches per hash de contingut en comptes de per l'id numèric que prenen els traits. Sourcehut accepta pedaços per correu, no com a merge request.

Cap d'aquestes retorna una llista buida. Una llista buida vol dir «no n'hi ha cap», i la veritat és «aquesta plataforma no té això», així que retornen un error que ho diu i assenyala què fa la plataforma al seu lloc. Una eina que retorna res en silenci t'ensenya a desconfiar de tots els resultats buits que et doni en el futur.

Repositoris replicats

Tan bon punt un repositori viu a més d'una plataforma, «la plataforma» és ambigu: cada backend té els seus pipelines, les seves releases i els seus paquets. --remote NAME en tria un:

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

Cadascun té també el seu token, així que operar sobre tots dos vol dir tenir-los tots dos configurats. L'opció és global dins de la seva comanda, cosa que vol dir que torii pipeline --remote NAME list i torii pipeline list --remote NAME són la mateixa frase amb les paraules en un altre ordre, i totes dues funcionen.

Què es deu encara

La visibilitat del repositori —passar de públic a privat— està cablejada només per a GitHub i GitLab. La família Gitea i Bitbucket exposen la mateixa crida i encara no estan connectades; Azure posa la visibilitat al projecte i no al repositori, així que allà la resposta honesta és un error que et porta als ajustos del projecte. És al full de ruta, i fins que arribi la taula de la pàgina de comparativa ho diu.