Loading search data...

Glab est devenue la cli officielle de gitlab

Publié le : 26 septembre 2022 | Mis à jour le : 22 janvier 2023

Introduction

logo

S’il y a bien quelque chose qui me manquait dans mes pipelines de CI/CD sous gitlab, c’est bien une CLI. Le trou est comblé avec l’annonce de l’intégration de glab comme CLI officielle de gitlab.

Ce manque nous obligeait à recourir à des appels sur l’API de gitlab. Cette pratique se révélait très fastidieuse à réaliser du fait l’obligation de devoir constituer la payload avant toute soumission. Des cas concrets : poser un tag, créer une release, …

Glab est écrit en go, et donc se révèle assez rapide et est inspirée de celle de github : gh.

Installation de glab

Tout est bien documenté et toutes les plateformes sont prises en charge : Windows, Linux, MacOs. Pour linux certaines distributions propose des packages glab : Alpine, Arch Linux et Nixos.

Pour installer l’autocomplétion, ajouter cette ligne dans votre .bashrc.

eval "$(glab completion -s bash)"

S’authentifier avec glab

Il faut au préalable créer un PAT, Personal Access Token, avec les droits api et write_registry au minima. C’est par . Donnez-lui un nom et stockez-la dans votre outil de secrets.

Pour s’authentifier, if faut utiliser l’option :

glab auth login

La commande demande sur quel type d’instance se connecter. Celle de gitlab.com ou celle de votre gitlab ?

Il vous demandera ensuite d’entrer votre token et le protocole de connexion
SSH, HTTPS ou HTTP.

Glab lance en fait des commandes config qui vont stocker votre configuration dans le dossier ~/.config/glab-cli/. Attention le token est stocké en clair donc ne mettez pas des droits permissifs dessus (par défaut 0600) !

Pour changer le type de connexion il suffira de taper la commande suivante pour modifier le type de connexion :

glab config set -h gitlab.com git_protocol ssh

Quelques commandes glab

La commande glab permet de gérer (l’option associée) :

  • Les issues : issue
  • Les labels : label
  • Les merge requests : mr
  • Les releases : release
  • Les repos : repo
  • Les clés SSH : ssh-key
  • Les user : user
  • Les variables : variable (variables de groupes et de projets)
  • Les pipelines : pipeline

Chacune de ses options utilise ensuite des verbes. Pour obtenir la liste un classique glab <option> --help vous retournera l’aide nécessaire.

Par exemple l’option variable utilise : delete, list, set et update.

Attention: Pour que la cli fonctionne sur certaines commandes il faut être dans un dossier contenant un projet gitlab ! Pour les autres il suffit d’ajouter l’option -R qui prend en argument le nom du repository ou son url (ssh,https ou http)

Gestion des repository

L’option repo permet de gérer les projets sur votre compte gitlab. On trouve ainsi comme option :

  • create : créer un repo avec possibilité de créer le répertoire sur la machine
  • delete : détruire un repo existant. Attention c’est le projet sur votre compte qui est détruit par le dossier en local.
  • fork : Création d’un fork d’un repo existant avec possibilité de le cloner localement.
  • archive: Archiver un projet, c’est-à-dire mis en lecture seule.
  • mirror : Ajout d’un mirroir
  • view : Affiche les informations d’un repository

Quelques exemples de commandes :

# Create
glab repo create --group glab-cli
glab repo create my-project
# Un projet privé dans un groupe (existant) avec initialisation du README.md
glab repo create glab-cli/my-project -d 'ma description' --private --readme -t ansible,devops

# Review
glab repo view my-project
glab repo view user/repo
glab repo view group/namespace/repo

Gestion des releases

Pour gérer les release on utilise l’option du même nom. Les commandes possibles sont :

  • create : pour créer une release.
  • delete : pour détruire une release existante
  • download : pour télécharger les assets d’une release
  • upload : pour stocker vos assets dans une release

Création d’une release

Pour créer une release, on utilise l’option create. Si cette release existe déjà elle sera automatiquement mise à jour.

glab release create <tag> [<files>...] [flags]

Si le tag spécifié n’existe pas encore, la version sera automatiquement créée à partir du dernier état de la branche par défaut et étiquetée avec le nom du tag spécifié. Il est possible d’utiliser une référence avec l’option -ref. Cette référence peut être un SHA de validation, un autre tag ou le nom d’une branche.

Il est possible d’ajouter des assets.

glab release create v1.0.1 '/dir/asset.zip#Mon label'

Lister les releases

On utilise la commande list :

glab release list

Showing 1 release on Bob74/aws-blog

Test   v1.0.0  about 16 minutes ago

Afficher le contenu d’une release

L’option view permet de récupérer toutes les informations d’une ou de toutes les releases :

glab release view [<tag>]

Test
Robert Stéphane released this about 17 minutes ago
111204ea - v1.0.0

ASSETS
There are no assets for this release
SOURCES
https://gitlab.com/Bob74/aws-blog/-/archive/v1.0.0/aws-blog-v1.0.0.zip
https://gitlab.com/Bob74/aws-blog/-/archive/v1.0.0/aws-blog-v1.0.0.tar.gz
https://gitlab.com/Bob74/aws-blog/-/archive/v1.0.0/aws-blog-v1.0.0.tar.bz2
https://gitlab.com/Bob74/aws-blog/-/archive/v1.0.0/aws-blog-v1.0.0.tar


View this release on GitLab at https://gitlab.com/Bob74/aws-blog/-/releases/v1.0.0

Ajouter des assets

Même si la release existe déjà, il est possible d’ajouter des assets avec la commande upload :

glab release upload v1.0.1 'aws-blog-v1.0.0.zip#Mon label#other'

Le # est utilisé comme séparateur :

  • Le premier est le nom du fichier à envoyer
  • Le second le nom du label. Attention : Ce nom est celui qui sera utilisé dans le téléchargement.
  • Le troisième est le type d’asset. Il peut prendre les valeurs other, package, image,… comme indiqué dans la doc de l’API Gitlab.

Télécharger les assets d’une release

Il est possible de télécharger les assets d’une release en spécifiant le répertoire de destination -d <path>. Pour limiter le téléchargement à un seul asset on utilise l’option -n.

glab release download -D /tmp -n aws-blog-v1.0.0.zip

Effacer une release

L’option delete permet de le faire :

glab release delete v1.0.0
• validating tag repo=Bob74/aws-blog tag=v1.0.0
This action will permanently delete release "v1.0.0" immediately.

? Are you ABSOLUTELY SURE you wish to delete this release "Test "? Yes
• deleting release repo=Bob74/aws-blog tag=v1.0.0
✓ release "Test " deleted

Rassurant par défaut, il demande une confirmation. Pour le forcer on ajoute l’option -y.

Gestion des pipelines

J’ai eu recours à cette option pipeline pour faire du ménage dans mes artefacts de jobs. N’ayant pas désactivé l’option Keep artifacts from most recent successful jobs dans les paramètres de certains dépôts, mon quota a été rapidement été atteint.

Nota : Pour ceux qui utilisent comme moi la version Free de gitlab.com le quota est calculé par Groupe et sa taille est de 10 Go. Pour contrôler l’état de votre quota par groupe, il faut se rendre dans settings/quota.

Lister les pipelines

Pour lister les pipelines, il suffit d’utiliser l’option list qui possède quelques arguments permettant :

  • d’indiquer le nombre de résultats retournés -P
  • de filtrer par status -s
  • d’indiquer l’ordre de tri

glab pipeline list –sort <asc|desc> -P -s <running|pending|success|failed|canceled|skipped|created|manual>

glab pipeline list --sort asc -P 5
Showing 5 pipelines on dockerfiles6/images/lastversion (Page 1)

(success)#681891944  renovate/gcr.io-distroless-python3-debian11  (about 5 days ago)
(success)#681922006  main                                         (about 5 days ago)
(success)#683972441  renovate/gcr.io-distroless-python3-debian11  (about 3 days ago)
(success)#684008106  main                                         (about 3 days ago)
(success)#686517884  main                                         (about 15 hours ago)

Effacer des pipelines

Cela se fait au moyen de la sous-commande delete. On peut par exemple détruire un pipeline avec son ID (3ème colonne), par son status avec l’option -s

glab pipeline delete v
glab pipeline delete , -s canceled

Pour faire du ménage rapidement, j’utilise cette ligne de commande :

for id in `glab pipeline list --sort asc -P 3| awk '{print substr($3,2)}'| tail -n+2`
do
glab pipeline delete $id
done

Cette ligne efface les 3 plus vieux pipelines. Pour en mettre plus changer juste la valeur après le -P.

Vous pouvez aussi choisir de ne conserver que les (n)derniers ou plus en jouant sur la valeur de tail :

for id in `glab pipeline list -P 500| awk '{print substr($3,2)}'| tail -n+5`
do
glab pipeline delete $id
done

Plus loin avec Glab

Maintenant que cette CI est officielle il va falloir réécrire une partie de nos pipelines CI/CD. Bonne nouvelle, c’est beaucoup simple que le recours à l'API de gitlab. Il faudra aussi l’ajouter dans les images que vous utilisez dans vos pipelines.

Plus d’infos

Mots clés :

devops gitlab tutorials

Si vous avez apprécié cet article de blog, vous pouvez m'encourager à produire plus de contenu en m'offrant un café sur  Ko-Fi. Vous pouvez aussi passer votre prochaine commande sur amazon, sans que cela ne vous coûte plus cher, via  ce lien . Vous pouvez aussi partager le lien sur twitter ou Linkedin via les boutons ci-dessous. Je vous remercie pour votre soutien.

Autres Articles


Commentaires: