GitHub a fêté il y a peu la première année d’existence de son projet open source GitHub CLI. L’interface en ligne de commande dédiée au logiciel de gestion de versions de code gagne du terrain auprès des développeurs, même si elle ne comprend pas encore toutes les fonctions de la mouture Web.
Lancé en février 2020, le projet GitHub CLI (sous licence MIT) est généralement disponible depuis septembre 2020. Depuis six mois, l’entreprise filiale de Microsoft a comptabilisé 700 000 pull requests jusqu’en février 2021. Même si l’interface en ligne de commande reste sous la maîtrise de Github, pas moins de 189 contributeurs participent à son développement.
« Nous avons enregistré une augmentation de 400 % du nombre d’utilisateurs actifs mensuels depuis l’annonce de GitHub CLI 1,0 », revendique Billy Griffin, Staff Engineering Manager chez GitHub. Cette ferveur, l’éditeur l’explique par le concept même du projet : fournir les fonctions du système de versions de code depuis un terminal. Le CLI est principalement employé par des « power users », des développeurs professionnels qui l’exploitent dans le cadre de leur travail, nous indique-t-on, mais il doit être également plus facile d’accès pour les débutants que son modèle, Hub.
« Nous avons apporté beaucoup d’améliorations pour éditer de nouvelles pull requests et issues, ainsi que les anciennes que vous n’auriez pas générées depuis GitHub CLI. »
Billy GriffinStaff Engineering Manager, GitHub
« Avec la version 1.0, nous supportions la plupart des fonctions disponibles depuis l’interface Web de GitHub, mais il y avait toujours des éléments liés à une pull request ou une requête issue que vous deviez effectuer depuis votre navigateur », remarque Billy Griffin. « Depuis nous avons apporté beaucoup d’améliorations pour éditer de nouvelles pull requests et issues, ainsi que les anciennes que vous n’auriez pas générées depuis GitHub CLI. Vous pouvez également réviser des métadonnées liées aux étiquettes et aux destinataires des pull requests et non plus seulement vous limiter aux titres et aux corps de texte ».
Le fait de pouvoir réaliser des alias de commande, des raccourcis, doit aussi faciliter la navigation pour les développeurs. Billy Griffin, lui, considère que le travail autour de l’authentification est à noter. « C’est très étrange que l’authentification soit une fonctionnalité intéressante, mais elle gère tout très bien pour vous et depuis quelques mois, nous vous permettons de télécharger une clé ssh et de la lier à votre compte dans le cadre de cette fonctionnalité. Si vous employez le protocole SSH pour travailler avec vos dépôts, vous n’avez plus besoin de créer une clé SSH sur GitHub.com et de la copier-coller, vous pouvez le faire directement depuis votre terminal ». De même, la gestion des secrets entre CLI et GitHub Actions est désormais embarquée.
Avec la version 1.7 annoncée en mars 2021, GitHub pousse plusieurs mises à jour incrémentales pour son CLI. La première étant l’ajout de gh repo list, une commande pour lister l’ensemble des dépôts accessibles par un utilisateur ou depuis un compte entreprise. Elle affiche également toutes les pull requests liées à un repo. Pour faciliter leur recherche, GitHub a inclus la possibilité d’installer des outils connexes tel un filtre, par exemple fzf (fuzzy finder command line).
L’éditeur espère aussi simplifier l’usage de l’API GitHub. La commande gh api permet de l’appeler directement depuis un script. « Gh api est incroyablement puissante, mais franchement, dans les anciennes versions, elle n’était pas facile à utiliser. Elle fonctionnait comme ces très longues chaînes API que vous devez construire, avec lesquelles vous devez savoir exactement ce que vous faites », explique Billy Griffin.
Il est possible d’ajouter des filtres en ayant recourt à la syntaxe de jq, un programme de ligne de commande pour n’afficher que les résultats d’une requête en JSON. « Jq transforme le résultat de ce qui serait autrement une sorte de JSON brut et le rend beaucoup plus convivial et compatible avec différentes commandes », résume l’ingénieur. La commande api --templates doit permettre de formater les résultats d’une requête via la génération de templates HTML en golang. « Avec les modèles, on peut organiser les choses par couleur, par mise en page, et de bien d’autres façons. Et ça rend tout ça beaucoup plus ergonomique », vante notre interlocuteur.
Plusieurs autres commandes permettent d’éditer une base de branches de pull requests, de formaliser leur clôture afin d’éviter des suppressions involontaires, ou encore d’écrire des messages et blocs de code plus longs.
GitHub promet une meilleure intégration avec Actions
Il y a six mois, Ryan Nystrom, directeur de l’ingénierie chez GitHub expliquait au MagIT que l’entreprise souhaitait « packager » GihtHub CLI et GitHub Actions, sa brique d’automatisation de flux afin d’écrire et de publier des scripts. C’est maintenant en partie le cas : GitHub CLI est préinstallé dans les environnements virtuels d’Actions.
Cela permet par exemple de paramétrer les phases de fusion automatique (auto-merge) via Actions.
Cependant, l’inverse n’est pas totalement vrai.
« Nous n’avons pas d’indicateurs sur la répartition entre les pull requests effectués par des humains ou via Actions, mais nous avons constaté de manière empirique une augmentation spectaculaire de l’utilisation de commandes gh au sein de flux de script et d’automatisation », assure Billy Griffin.
« Dans les prochains mois, nous allons implémenter une fonctionnalité majeure pour superviser les flux en cours de progression. »
Billy GriffinStaff Engineering Manager, GitHub
Cependant, « cela est différent du fait d’utiliser le CLI pour gérer GitHub Actions. Dans les prochains mois, nous allons implémenter une fonctionnalité majeure pour superviser les flux en cours de progression, ce qu’aujourd’hui vous pouvez partiellement faire avec la commande gh pr checks. Cela permettra d’observer les vérifications qui ont réussi ou échouer, plus seulement sur une pull request, mais dans tous les flux d’un dépôt, de chercher plus facilement ce qui cause des problèmes », promet-il. « Nous avons déjà pu bénéficier de cette fonctionnalité et nous pensons que beaucoup de gens pourront en profiter ».
L’influence de la communauté
Une autre fonctionnalité « intéressante » provient directement de la communauté. Au lieu de passer par un outil externe de filtrage comme fzf, GitHub et les contributeurs élaborent un mécanisme de recherche plus aboutie. « Nous travaillons sur un indicateur de recherche dans les issues et les pull requests. Pour que vous puissiez obtenir une sorte d’équivalent à la barre de recherche accessible en haut de page GitHub.com », renseigne notre interlocuteur.
Ce serait, à date, la contribution la plus importante en provenance de la communauté open source. « Jusqu’alors, GitHub a mené la direction du produit et les contributeurs ont davantage amélioré l’expérience utilisateur avec la possibilité de supprimer des issues ou encore la proposition de la commande gh repo list. Mais nous n’avions pas vu de grandes fonctionnalités qui changent la donne. Je pense que les indicateurs de recherche (search flag en anglais) entrent dans cette catégorie », considère Billy Griffin.
Ces deux capacités devraient être disponibles dans la version 2.0.
GitHub CLI, enfin capable de tenir la dragée haute à Hub
En ce qui concerne la différenciation entre GitHub CLI et Hub, Billy Griffin maintient son postulat de départ, à savoir que « les utilisateurs peuvent employer l’outil de leur choix, celui qui les rend plus productifs, tant qu’ils utilisent GitHub », déclare-t-il amusé. « Je vois souvent sur Twitter des gens qui expliquent qu’ils sont passés de Hub à GitHub CLI parce que l’outil est devenu puissant. Au moment de la bêta, Hub était bien meilleur pour gérer les flux de scripts. Avec la dernière version à date, nous nous sommes concentrés sur les éléments de scripting plus précis que les utilisateurs essayent d’obtenir. Donc, je pense que si vous commencez aujourd’hui il n’y a pas vraiment de raison d’utiliser Hub plutôt que GitHub CLI ».
Reste aussi à ajouter des fonctionnalités natives plus avancées ou spécifiques à certains usages. Par exemple, Matt Moore, le cofondateur de Knative (un projet pour exécuter des fonctions serverless sur Kubernetes) demandait le 27 mars sur Twitter s’il existe une commande pour rendre publiques des images de conteneurs. Ce à quoi Ross Edman, ancien ingénieur logiciel chez GitHub depuis passé chez Equinix, répond qu’il peut pour l’instant développer son script via l’API GitHub et la commande alias.
C’est ce genre d’amélioration que souhaite apporter à l’avenir l’équipe derrière GitHub CLI. « Nous voyons des gens partager des scripts qu’ils ont bâtis en utilisant gist, fait à partir de gh, ce qui est plutôt bien, mais je pense qu’il y a une opportunité de l’étendre encore plus et de vous permettre de partager et de personnaliser les choses que vous pouvez faire avec GitHub CLI », indique Billy Griffin.
Et ce travail d’abstraction demande un cheminement particulier à l’équipe en charge du projet. « Quand GitHub.com bénéficie d’une nouvelle fonctionnalité, nous nous demandons souvent avec les ingénieurs et les designers des autres équipes à quoi elle ressemblerait dans CLI. Un terminal ne laisse pas beaucoup de place à des éléments comme des boutons ou des indicateurs visuels, vous devez vous contenter de la rendre aussi claire et évidente que possible », remarque le responsable de l’ingénierie. « Nous travaillons très étroitement avec l’équipe d’Actions lorsque l’on bâtit les flux actions depuis GitHub CLI », conclut-il.
