La Forge - crates sur Gitlab

Partie 3: Gestion des workspaces

2024-04-24T00:00:00+00:00

Les articles de la série

Bonjour à toutes et à tous 😀

Dans le précédent article, nous avons créé un pipeline de création de package à la fois de release et de pre-release pour un projet mono-crate.

Mais en Rust, il existe un mécanisme très utilisés qui se nomme les workspaces.

Ce sont des environnement de crates liées qui permettent de découper un projet lorsqu’il devient trop volumnineux ou lorsque le besoin de partager des données se fait sentir.

Workspace

Pour créer un workspace, on peut taper.

echo [workspace] >  Cargo.toml
cargo new --lib w1

Une ligne va venir se rajouter dans le Cargo.toml

Cargo.toml

[workspace]
members = ["w1"]

Et on peut rajouter autant de sous crates que l’on veut

cargo new --lib w2
cargo new --lib w3

Si l’on tente de faire

cargo package --allow-dirty

Il va le faire pour w1, w2 et w3.

C’est en soit cool, mais pas très intéressant pour nous.

Généralement les crates d’un workspace ont des cycles de versions disjoint, autrement dit ce n’est pas parce que w1 change de version que c’est le cas de w2 et de w2.

Heureusement il est possible de scoper le package à créer

cargo package -p w1 --allow-dirty

Parfait et maintenant les métadonnées.

Il est nécessaire au bon fonctionnement de la registry et ce n’est pas grave en soit que le workspace complet y soit décrit.

On vient juste s’assurer que les dépendences ne soient pas prise en compte avec

cargo metadata --format-version 1 --no-deps > metadata.json

On va donc utiliser une variable CRATE_PACKAGE

variables:
  CRATE_PACKAGE: ""

Qui va venir contrôler le package à créer.

cargo package -p $CRATE_PACKAGE --allow-dirty

Ok, et donc on contrôle comment cette variable ?

Alors on peut le faire depuis les variables de CI externes, mais ce n’est pas pratique.

Au lieu de ça, je vous propose d’utiliser ce que l’on appelle les matrix, cela permet de faire tourner en parrallèle plusieurs jobs d’un même type mais configuré différemment.

Première étape on invisibilise la tâche de release-prod en la suffixant d’un point .release-prod.

.release-prod:
  image: rust:1.77
  stage: packaging
  # seulement si c'est main
  only:
    - main
  script:
    - *prepare
    - *packaging

Puis on utilise la composition et matrix.

release-prod:
  extends: .release-prod
  when: manual
  parallel:
    matrix:
      - CRATE_PACKAGE: w1
      - CRATE_PACKAGE: w2
      - CRATE_PACKAGE: w3

Nous avons maintenant un pipeline qui permet de créer de manière indépendante des versions de releases.

Récupérer la version

Mais il reste une question en suspend.

Comment récupérer le nom et la version du package ciblé, pour le nom on l’a déjà mais nous allons tout de même le reconstruire pour être certain.

Pour faire cela, nous allons utiliser la commande cargo metadata pour lister les packages existants:

cargo metadata --format-version 1 --no-deps | jq

Nous obtenons ce json pour un workspace

{
  "packages" : [
    {
      "name" : "w1",
      "version" : "0.1.0",
      "manifest_path" : "/path/to/workspace/w1/Cargo.toml" 
    },
    {
      "name" : "w2",
      "version" : "0.1.0",
      "manifest_path" : "/path/to/workspace/w2/Cargo.toml" 
    },
    {
      "name" : "w3",
      "version" : "0.1.0",
      "manifest_path" : "/path/to/workspace/w3/Cargo.toml" 
    }
  ],
  // ...
}

Et celui-ci pour un projet “simple”

{
  "packages" : [
    {
      "name" : "subber",
      "version" : "0.1.0",
      "manifest_path" : "/path/to/subber/Cargo.toml" 
    },
  ],
  // ...
}

Nous avons donc 2 cas à traiter:

Le premier on cherche à récupérer la version d’un package explicitement nommé par la variable $CRATE_PACKAGE
Le second est le cas implicite d’un état à un package et l’absence de variable $CRATE_PACKAGE

Comment procède-t-on ?

Et bien jq est bien plus qu’il ne semble être.

Il est par exemple possible de créer des conditions qui vont venir créer des branches d’exécutions.

Notre algorithm va être:

SI la "taille du tableau de package" est supérieur à 1
ALORS
  SELECTIONNER le package qui possède le nom == $CRATE_PACKAGE
SINON
  SELECTIONNER le premier package
END

En jq cela nous donne

if (.packages | length ) > 1 
then 
(.packages[] | select(.name == $PACKAGE)) 
else 
.packages[0] 
end

Puis nous pouvons récupérer ce qui nous intéresse

{"name" : .name, "version": .version, "manifest": .manifest_path}

On export le résultat dans une variable $PACKAGE_DATA

export PACKAGE_DATA=$(cargo metadata --format-version 1 --no-deps | jq --arg PACKAGE "$CRATE_PACKAGE" '(if (.packages | length ) > 1 then (.packages[] | select(.name == $PACKAGE)) else .packages[0] end) | {"name" : .name, "version": .version, "manifest": .manifest_path}')

Ensuite, nous mettons en place un garde-fou, qui a deux rôle:

vérifier que au moins un package existe dans le workspace
vérifier que le package sélectionné existe

Pour cela on vérifie que la variable n’est pas vide sinon on quitte

[ -z "$PACKAGE_DATA" ] && echo "Unknown package $PACKAGE in workspace" && exit 1

Ensuite, on récupère tranquillement:

la version
le Cargo.toml du package
le nom du package

export CRATE_NAME=$(jq ".name" <<< "$PACKAGE_DATA" | tr -d '"')
export CRATE_VERSION=$(jq ".version" <<< "$PACKAGE_DATA" | tr -d '"')
export CARGO_FILE=$(jq ".manifest" <<< "$PACKAGE_DATA" | tr -d '"')

Dépendances transitives

Mais il y a un autre souci, un de plus 😝

Pour créer les versions flottantes, nous modifions le Cargo.toml du package voulu

Mais ça cargo n’aime pas du tout, si dans ses dépendences il y a

w2/Cargo.toml

[package]
name = "w2"
[dependencies]
w1 = {path="../w1", version = "0.2.0", registry="private-crates"}

Et que l’on s’amuse à transformer la version du package w1

w2/Cargo.toml

[package]
name = "w1"
version = "0.2.0-124eba69"

Cargo va pas être content car il ne s’attend pas à cette version et n’a plus de repère pour créer le package

if you are looking for the prerelease package it needs to be specified explicitly
    w1 = { version = "0.2.0-124eba69" }

Il faut donc aller trafiquer le Cargo.toml de w2 pour lui donner la bonne version.

w2/Cargo.toml

[package]
name = "w2"
[dependencies]
# dynamiquement modifié
w1 = {path="../w1", version = "0.2.0-124eba69", registry="private-crates"}

Et ce, pour toutes les packages utilisant w1 dans le workspace.

Ok, on fait ça comment ?

La manière la plus “simple” est de lister les ‘Cargo.toml’

cargo metadata --format-version 1 --no-deps | jq -r '.packages[] | .manifest_path | tostring

En suite on liste en suite les dépendences qui possède w1.

tomlq '.dependencies' w2/Cargo.toml | jq ."w1"

Renvera

{
  "path": "../w1",
  "version": "0.1.0-toto"
}

Par contre

tomlq '.dependencies' w1/Cargo.toml | jq ."w1"

Renvera

null

Il est ainsi possible de fail fast sur les Cargo.toml qui ne nous intéressent pas.

Ensuite il suffit de réaliser le remplacement dans le toml

tomlq -t '.dependencies.w1.version = "0.2.0-124eba69"' w2/Cargo.toml

Ce serait si simple si cela marchait aussi facilement mais il y a un soucis

Lorque que l’on tente de variabiliser

tomlq --arg PAKAGE w1  -t ".dependencies.$PACKAGE.version = "0.2.0-124eba69"" w2/Cargo.toml

On arrive sur cette erreur

jq: error: syntax error, unexpected '$', expecting FORMAT or QQSTRING_START (Unix shell quoting issues?) at <top-level>, line 1:
.dependencies.$PACKAGE.version = "0.2.0-124eba69

La solution de déport que j’ai trouvé est de templatiser l’expression à coup de bash expansion

FILE=w2/Cargo.toml
PACKAGE=w1
VERSION=0.2.0-124eba69
COMMAND=$(tomlq -t ".dependencies.$PACKAGE.version = \"$VERSION\"" "$FILE")
echo "$COMMAND"

Et cette fois-ci c’est fonctionnel !

[package]
name = "w2"
[dependencies]
w1 = {path="../w1", version = "0.2.0-124eba69", registry="private-crates"}

On se rapproche, maintenant, nous voulons appliquer cette modification à tous les sous package.

Nous sommes capable de les lister, plus qu’à appliquer.

Et pour ça il nous faut un autre outil qui se nomme xargs, c’est une usine à gaz, donc je ne vais pas rentrer dans les détails mais l’idée ici c’est qu’il va prendre les résultat ligne par ligne et les appliquer à des traitements.

Par exemple

$ cat toto
titi
tata
tutu
$ cat toto | xargs -I {} echo {}+suffix

Cela affichera

titi+suffix
tata+suffix
tutu+suffix

Si vous êtes sur windows wsl, attention a bien créer le fichier sans CRLF, xargs ne prend en compte que le LF et traite le CR comme un caractère indifférent.

On vient créer un script à coup de heredoc

cat << 'EOF' > ~/upgrade-cargo.sh
        FILE=$1
        PACKAGE=$2
        VERSION=$3
      
        result=$([ "null" != "$(tomlq '.dependencies' "$FILE" | jq ."$PACKAGE")" ] && tomlq -t ".dependencies.$PACKAGE.version = \"$VERSION\"" "$FILE")
        [ -n "$result" ] && echo "$result" > "$FILE"
        exit 0
      EOF

Et finalement on rassemble tout !

cargo metadata --format-version 1 --no-deps | jq -r '.packages[] | .manifest_path | tostring' |  xargs -I {}  bash ~/upgrade-cargo.sh {} $PACKAGE $CRATE_VERSION

.gitlab-ci.yml

stages:
  - packaging

variables:
  # gitlab token
  CRATE_PACKAGE_TOKEN: $CI_JOB_TOKEN
  # l'ID du projet qui supportera les crates par défaut le project du job
  CRATE_PACKAGE_PROJECT_ID: $CI_PROJECT_ID
  # API user
  CRATE_PACKAGE_USER_API: JOB-TOKEN
  # Host du proxy SSH
  CRATE_PACKAGE_ENDPOINT: noa-crates.cleverapps.io
  # Port d'écoute du proxy SSH
  CRATE_PACKAGE_PORT: 22066
  # Utilisateur associé au token
  CRATE_PACKAGE_USER: personal-token
  # Package ciblé
  CRATE_PACKAGE: ""

.dependencies: &dependencies
  # dépendences
  - apt update && apt install -y yq

.ssh-connexion: &ssh-connexion
  # configuration SSH
  - mkdir -p ~/.ssh && chmod -R 700 ~/.ssh
  - |
    cat << EOF > ~/.ssh/config 
    Host $CRATE_PACKAGE_ENDPOINT
        User $CRATE_PACKAGE_USER:$CRATE_PACKAGE_TOKEN
        Port $CRATE_PACKAGE_PORT
    EOF
  # création de la paire de clefs
  - ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
  # ajout de la clef publique du proxy
  - ssh-keyscan -p $CRATE_PACKAGE_PORT $CRATE_PACKAGE_ENDPOINT >> ~/.ssh/known_hosts

.packaging: &packaging
  # packaging
  - cargo package -p $PACKAGE --allow-dirty
  - cargo metadata --format-version 1 > metadata.json
  - ls target/package/$CRATE_FILE
  # upload
  - 'curl -i --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file target/package/${CRATE_FILE} "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/$CRATE_FILE"'
  - 'curl -i --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file metadata.json "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/metadata.json"'

.version: &version
  # récupération des informations du paquet
  - |
     export PACKAGE_DATA=$(cargo metadata --format-version 1 --no-deps | jq --arg PACKAGE "$PACKAGE" '(if (.packages | length ) > 1 then (.packages[] | select(.name == $PACKAGE)) else .packages[0] end) | {"name" : .name, "version": .version, "manifest": .manifest_path}')
  # on quitte si le package n'existe
  - '[ -z "$PACKAGE_DATA" ] && echo "Unknown package $PACKAGE in workspace" && exit 1'
  - export CRATE_NAME=$(jq ".name" <<< "$PACKAGE_DATA" | tr -d '"')
  - export CRATE_VERSION=$(jq ".version" <<< "$PACKAGE_DATA" | tr -d '"')
  - export CARGO_FILE=$(jq ".manifest" <<< "$PACKAGE_DATA" | tr -d '"')
  - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate

.prepare: &prepare
  - *dependencies
  - *ssh-connexion
  - *version

.release-dev:
  image: rust:1.77
  stage: packaging
  # manuel
  when: manual
  # si la branche n'est pas main
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script:
    - *prepare
    # on créé la version flottante
    - export CRATE_VERSION=$CRATE_VERSION-$CI_COMMIT_SHORT_SHA
    - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate
    - |
      cat << 'EOF' > ~/upgrade-cargo.sh
        FILE=$1
        PACKAGE=$2
        VERSION=$3
      
        result=$([ "null" != "$(tomlq '.dependencies' "$FILE" | jq ."$PACKAGE")" ] && tomlq -t ".dependencies.$PACKAGE.version = \"$VERSION\"" "$FILE")
        [ -n "$result" ] && echo "$result" > "$FILE"
        exit 0
      EOF
    # On remplace la version
    - |
      cargo metadata --format-version 1 --no-deps | jq -r '.packages[] | .manifest_path | tostring' |  xargs -I {}  bash ~/upgrade-cargo.sh {} $PACKAGE $CRATE_VERSION
    - tomlq --arg VERSION $CRATE_VERSION -t '.package.version = $VERSION' $CARGO_FILE > Cargo.toml.modified
    - mv Cargo.toml.modified $CARGO_FILE
    - *packaging

.release-prod:
  image: rust:1.77
  stage: packaging
  # seulement si c'est main
  only:
    - main
  script:
    - *prepare
    - *packaging

release-dev:
  extends: .release-dev
  when: manual
  parallel:
    matrix:
      - PACKAGE: w1
      - PACKAGE: w2
      - PACKAGE: w3

release-prod:
  extends: .release-prod
  when: manual
  parallel:
    matrix:
      - PACKAGE: w1
      - PACKAGE: w2
      - PACKAGE: w3

Partie 2: Pipeline de CI

2024-04-22T00:00:00+00:00

Les articles de la série

Bonjour à toutes et à tous 😀

Dans l’article précédent nous avons poussé à la main des crates en utilisant curl en local.

Ce n’est pas du tout satisfaisant.

Nous allons automatiser tout ça via la CI. Et comme nous avons commencé avec la package registry de Gitlab, on va également utilisé la Gitlab CI.

J’ai un certain nombre d’exigences.

une adresse unique pour toutes les crates, je ne veaux pas à avoir à me rappeler du chemin à chaque fois
le versionnage est explicite et basé sur la version du package publié
support des versions flottantes de dev
ces versions de devs ont un versionnage implicite et automatique
cela doit être le moins contraignant à utiliser, le moins de boilerplate possible
il doit gérer les workspace Rust

Autant dire qu’il y a un peu de travail.

Pipeline de CI 1o1

Commençons par la base.

Si vous créez un fichier .gitlab-ci.yml à la racine d’un projet git et que vous le poussez sur Gitlab, cela va indiquer à Gitlab qu’il faut lancer un pipeline de CI.

Son format est le suivant

.gitlab-ci.yml

stages:
    - stage1
    - stage2

job1:
    stage: stage1

job2:
    stage: stage1

job3:
    stage: stage2

Cela créé un graphe d’exécution qui va ressembler à ceci

  

flowchart LR
    job1 -->job3
    job2 --> job3

job1 et job2 doivent tous les deux réussir si l’on veut que job3 s’exécute. Ce système de strates se nomme des stages et permettent de réaliser des checkpoints bloquants entre les différentes étapes.

Par exemple ne packager que si le build est un succès est une bonne idée. 😎

Nous nous allons définir un stage qui s’appellera package.

Bon et maintenant, qu’est ce que l’on fait de nos jobs ?.

La première chose est de définir une image qui sera notre environnement de packaging, nous faisons du rust, ça sera donc une image rust. Et de préférence versionnée.

.gitlab-ci.yml

package-crate:
    image: rust:1.77
    stage: packaging

Nous allons écrire du bash, ce qui reste la meilleure façon d’intéragir avec un environnement.

Et ce bash vient se mettre dans un array nommé scripts.

.gitlab-ci.yml

package-crate:
    image: rust:1.77
    stage: packaging
    script: 
        - echo "Hello World"

Packaging en CI

D’abord récapitulons ce que nous avons fait en local:

nous avons défini un .ssh/config contenant le host de notre proxy
nous avons lancé les commandes de packaging
nous avons fait du curl

Ok, mimons ce fonctionnement.

Tout d’abord occupons-nous du SSH.

La première chose que l’on va faire c’est définir des informations sous forme de variable d’environnement

.gitlab-ci.yml

variables:
    CRATE_PACKAGE_ENDPOINT=$CRATES_ENDPOINT
    CRATE_PACKAGE_USER=personal-token

Bien maintenant le packaging en lui-même.

Il nécessite plusieurs éléments:

l’addresse de l’API gitlab trouvable dans la variable injectée $CI_API_V4_URL
la version du package
le nom du package
le chemin vers le fichier .crate à générer à partier des informations précédentes
le token que l’on possède déjà

Pour rappel, cela à cette tête-là:

curl --header "PRIVATE-TOKEN: $TOKEN" --upload-file target/package/${CRATE_FILE} "${ENDPOINT}/projects/${PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/$CRATE_FILE"

Commençons par récupérer le nom et la version du package.

Pour cela nous pouvons utiliser un utiliser un utilitaire qui se nomme tomlq, il vient avec yq et permet de réaliser des requêtes jq sur un fichier toml.

Pour cela, on se rajoute la dépendance.

apt update && apt install -y yq

Puis on génère nos variables.

export CRATE_NAME=$(tomlq '.package.name' Cargo.toml  | tr -d '"')
export CRATE_NAME=$(tomlq '.package.version' Cargo.toml  | tr -d '"')

On vient “trim” les guillemets qui vont nous ennuyer par la suite.

On peut alors constituer notre $CRATE_FILE

export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate

Il nous faut également un $CRATE_PACKAGE_PROJECT_ID que l’on défini dans les variables d’environement

Nous avons tous les ingédients, nous pouvons créer notre job.

.gitlab-ci.yml

stages:
  - packaging

variables:
  # gitlab token
  CRATE_PACKAGE_TOKEN: $CI_JOB_TOKEN
  # l'ID du projet qui supportera les crates par défaut le project du job
  CRATE_PACKAGE_PROJECT_ID: $CI_PROJECT_ID
  # API user
  CRATE_PACKAGE_USER_API: JOB-TOKEN

package-crate:
  image: rust:1.77
  stage: packaging
  script:
    # dépendences
    - apt update && apt install -y yq
    # récupération des informations du paquet
    - export CRATE_NAME=$(tomlq '.package.name' Cargo.toml  | tr -d '"')
    - export CRATE_VERSION=$(tomlq '.package.version' Cargo.toml  | tr -d '"')
    - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate
    # packaging
    - cargo package
    - cargo metadata --format-version 1 > metadata.json
    # upload
    - 'curl --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file target/package/${CRATE_FILE} "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/$CRATE_FILE"'
    - 'curl --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file metadata.json "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/metadata.json"'

Si tout se passe bien, vous devriez voir apparaître dans la package registry de votre projet Gitlab un paquet project v0.1.0.

Maintenant intéressons nous au cas où le projet nécessite une dépendence qui elle même est privée.

On se créé un projet pour tester.

cargo init --lib need_project && cd need_project
mkdir -p .cargo && cat << EOF > .cargo/config
[registries.private-crate]
index = "ssh://noa-crates.cleverapps.io/noa-crates/project"
[net]
git-fetch-with-cli = true
EOF
echo  'project = {version="0.1.0", registry="private-crate"}' >> Cargo.toml

Comme vous pouvez le voir, nous allons devoir nous authentifier.

Pour cela nous définissons dans l’objet variables les différentes informations nécessaire à la connexion SSH.

.gitlab-ci.yml

variables:
    CRATE_PACKAGE_TOKEN: $CI_JOB_TOKEN
    CRATE_PACKAGE_ENDPOINT: noa-crates.cleverapps.io
    CRATE_PACKAGE_PORT: 22066
    CRATE_PACKAGE_USER: personal-token

On créé le répertoire .ssh avec les bons droits

mkdir -p ~/.ssh && chmod -R 700 ~/.ssh

Via heredoc nous générons la configuration SSH:

cat << EOF > ~/.ssh/config 
Host $CRATE_PACKAGE_ENDPOINT
    User $CRATE_PACKAGE_USER:$CRATE_PACKAGE_TOKEN
    Port $CRATE_PACKAGE_PORT
EOF

Mais cela n’est pas suffisant, il faut également générer une clef privée pour que la connexion SSH se fasse.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Et finalement récupérer la clef publique de notre proxy SSH, sinon la connexion échouera en non-intéractif car le endpoint n’est pas “connu”.

ssh-keyscan -p $CRATE_PACKAGE_PORT $CRATE_PACKAGE_ENDPOINT >> ~/.ssh/known_hosts

Ok, notre job de CI est maintenant capable de réaliser notre authentification au proxy.

Nous pouvons rassembler les pièces du puzzle

.gitlab-ci.yml

stages:
  - packaging

variables:
  # gitlab token
  CRATE_PACKAGE_TOKEN: $CI_JOB_TOKEN
  # l'ID du projet qui supportera les crates par défaut le project du job
  CRATE_PACKAGE_PROJECT_ID: $CI_PROJECT_ID
  # API user
  CRATE_PACKAGE_USER_API: JOB-TOKEN
  # Host du proxy SSH
  CRATE_PACKAGE_ENDPOINT: noa-crates.cleverapps.io
  # Port d'écoute du proxy SSH
  CRATE_PACKAGE_PORT: 22066
  # Utilisateur associé au token
  CRATE_PACKAGE_USER: personal-token

package-crate:
  image: rust:1.77
  stage: packaging
  script:
    # dépendences
    - apt update && apt install -y yq
    # configuration SSH
    - mkdir -p ~/.ssh && chmod -R 700 ~/.ssh
    - |
        cat << EOF > ~/.ssh/config 
        Host $CRATE_PACKAGE_ENDPOINT
            User $CRATE_PACKAGE_USER:$CRATE_PACKAGE_TOKEN
            Port $CRATE_PACKAGE_PORT
        EOF
    # création de la paire de clefs
    - ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
    # ajout de la clef publique du proxy
    - ssh-keyscan -p $CRATE_PACKAGE_PORT $CRATE_PACKAGE_ENDPOINT >> ~/.ssh/known_hosts
    # récupération des informations du paquet
    - export CRATE_NAME=$(tomlq '.package.name' Cargo.toml  | tr -d '"')
    - export CRATE_VERSION=$(tomlq '.package.version' Cargo.toml  | tr -d '"')
    - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate
    # packaging
    - cargo package
    - cargo metadata --format-version 1 > metadata.json
    # upload
    - 'curl --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file target/package/${CRATE_FILE} "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/$CRATE_FILE"'
    - 'curl --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file metadata.json "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/metadata.json"'

Et là c’est le drame 😫

fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

Oui, votre $CI_JOB_TOKEN n’a de droit que sur le projet need_project pas project.

Mais heureusement, il est possible de régler le souci en passant en paramètre du job un token apte à intéragir avec les deux projets, pour Gitlab SaaS en gratuit nous n’avons pas le choix, ça sera forcément des token personnels, mais pour des version self-hosted, il est possible de créer des group token.

Bref, dans la configuration de la CI du projet need_project rajouté une variable d’environnement CRATE_PACKAGE_TOKEN avec votre token.

Il faut également redéfinir le CRATE_PACKAGE_USER_API à PRIVATE-TOKEN

On relance

Si tout est correct,

Votre pipeline devrait afficher quelque part ceci:

$ cargo package
warning: manifest has no description, license, license-file, documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.
   Packaging need_project v0.1.0 (/builds/noa-crates/need_project2)
   Verifying need_project v0.1.0 (/builds/noa-crates/need_project2)
    Updating `private-crate` index
From ssh://noa-crates.cleverapps.io/noa-crates/project
 * [new ref]                    -> origin/HEAD
 Downloading crates ...
  Downloaded project v0.1.0 (registry `private-crate`)
   Compiling project v0.1.0 (registry `private-crate`)
   Compiling need_project v0.1.0 (/builds/noa-crates/need_project2/target/package/need_project-0.1.0)
    Finished dev [unoptimized + debuginfo] target(s) in 3.00s

Cela prouve que votre arbre de dépendences privée est bien reconstruite en CI. 🤩

Succès ⁉️

Oui et non, c’est très contraignant de connaître toute cette mécanique, on ne gère pas encore les workspace et les versions de pre-release sont impossible à réaliser en l’état.

Bref on repars en chasse !

Versions de pre-release

Qu’est ce qu’une version de pre-release pour moi ?

Une version de pre-release c’est une version pas fini mais qui est nécessaire de packager pour d’autres développements.

Si on se fie à la notation semver suivie par cargo.

Il est possible de créer des versions qui ne sont pas “finies” en les suffixant d’un attribut.

par exemple 1.0.0-alpha.0, le suffixe de version alpha.0 indique la notion de pre-release de cette 1.0.0.

Mais on peut y mettre ce que l’on désire comme le SHA1 réduit de 8 caratères du commit de version.

C’est ce que j’ai décidé de faire pour générer des versions comme 1.0.2-2e92f1ff.

Pour cela nous allons concaténer la version récupérer du Cargo.toml et la joindre au contenu de la varaible $CI_COMMIT_SHORT_SHA injecté par le job.

export CRATE_VERSION=$CRATE_VERSION-$CI_COMMIT_SHORT_SHA

Ok easy non ?

Alors non, si vous tentez de faire ça comme cela, la commande cargo package n’utilisera pas votre version modifiée et créera un target/package/project-0.1.0.crate au lieu du target/package/project-0.1.0-2e92f1ff.crate voulu.

Il va falloir trafiquer le Cargo.toml pour mettre à jour la version.

tomlq permet au moyen du paramètre --arg d’injecter de l’environnement.

tomlq --arg VERSION $CRATE_VERSION -t '.package.version = $VERSION' Cargo.toml > Cargo.toml.modified
mv Cargo.toml.modified Cargo.toml

Et il faut également rajouter un paramètre --allow-dirty pour packager sans avoir à commiter.

cargo package --allow-dirty

On est bon ?

Presque.

Il faut que l’on découple les run entre la branche main et les autres: je veux que le package de release ne se déclenche que sur la branche main et pas ailleurs.

Et je veux également que le run du packaging de pre-release soit une tâche manuelle.

Heuresement Gitlab Ci permet de configurer tout ceci.

.gitlab-ci.yml

stages:
    - packaging

release-dev:
    stage: packaging
    # nécessite une intervention humaine
    when: manual
    # si la branche n'est pas main
    rules:
      - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH

release-prod:
    stage: packaging
    # seulement si c'est main
    only:
    - $CI_DEFAULT_BRANCH

Et maintenant on rempli

stages:
    - packaging

variables:
  # gitlab token
  CRATE_PACKAGE_TOKEN: $CI_JOB_TOKEN
  # l'ID du projet qui supportera les crates par défaut le project du job
  CRATE_PACKAGE_PROJECT_ID: $CI_PROJECT_ID
  # API user
  CRATE_PACKAGE_USER_API: JOB-TOKEN
  # Host du proxy SSH
  CRATE_PACKAGE_ENDPOINT: noa-crates.cleverapps.io
  # Port d'écoute du proxy SSH
  CRATE_PACKAGE_PORT: 22066
  # Utilisateur associé au token
  CRATE_PACKAGE_USER: personal-token

release-dev:
  image: rust:1.77
  stage: packaging 
  # nécessite une intervention humaine
  when: manual
  # si la branche n'est pas main
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script:
    # dépendences
    - apt update && apt install -y yq
    # configuration SSH
    - mkdir -p ~/.ssh && chmod -R 700 ~/.ssh
    - |
        cat << EOF > ~/.ssh/config 
        Host $CRATE_PACKAGE_ENDPOINT
            User $CRATE_PACKAGE_USER:$CRATE_PACKAGE_TOKEN
            Port $CRATE_PACKAGE_PORT
        EOF
    # création de la paire de clefs
    - ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
    # ajout de la clef publique du proxy
    - ssh-keyscan -p $CRATE_PACKAGE_PORT $CRATE_PACKAGE_ENDPOINT >> ~/.ssh/known_hosts
    # récupération des informations du paquet
    - export CRATE_NAME=$(tomlq '.package.name' Cargo.toml  | tr -d '"')
    - export CRATE_VERSION=$(tomlq '.package.version' Cargo.toml  | tr -d '"')
    # on créé la version flottante
    - export CRATE_VERSION=$CRATE_VERSION-$CI_COMMIT_SHORT_SHA
    - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate
    # On remplace la version
    - tomlq --arg VERSION $CRATE_VERSION -t '.package.version = $VERSION' Cargo.toml > Cargo.toml.modified
    - mv Cargo.toml.modified Cargo.toml
    # packaging
    - cargo package --allow-dirty
    - cargo metadata --format-version 1 > metadata.json
    # upload
    - 'curl --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file target/package/${CRATE_FILE} "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/$CRATE_FILE"'
    - 'curl --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file metadata.json "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/metadata.json"'

release-prod:
  image: rust:1.77
  stage: packaging
  # seulement si c'est main
  only:
    - $CI_DEFAULT_BRANCH
  script:
    # dépendences
    - apt update && apt install -y yq
    # configuration SSH
    - mkdir -p ~/.ssh && chmod -R 700 ~/.ssh
    - |
        cat << EOF > ~/.ssh/config 
        Host $CRATE_PACKAGE_ENDPOINT
            User $CRATE_PACKAGE_USER:$CRATE_PACKAGE_TOKEN
            Port $CRATE_PACKAGE_PORT
        EOF
    # création de la paire de clefs
    - ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
    # ajout de la clef publique du proxy
    - ssh-keyscan -p $CRATE_PACKAGE_PORT $CRATE_PACKAGE_ENDPOINT >> ~/.ssh/known_hosts
    # récupération des informations du paquet
    - export CRATE_NAME=$(tomlq '.package.name' Cargo.toml  | tr -d '"')
    - export CRATE_VERSION=$(tomlq '.package.version' Cargo.toml  | tr -d '"')
    - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate
    # packaging
    - cargo package
    - cargo metadata --format-version 1 > metadata.json
    # upload
    - 'curl --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file target/package/${CRATE_FILE} "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/$CRATE_FILE"'
    - 'curl --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file metadata.json "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/metadata.json"'

Si l’on

git checkout -b `dev
git push --set-upstream origin dev

Un pipeline avec une tâche manuelle va apparaître

Et dedans normalement

$ cargo package --allow-dirty
   Packaging need_project v0.1.0-0eb85488 (/builds/noa-crates/need_project2)
   Verifying need_project v0.1.0-0eb85488 (/builds/noa-crates/need_project2)
    Updating `private-crate` index
From ssh://noa-crates.cleverapps.io/noa-crates/project
 * [new ref]                    -> origin/HEAD
 Downloading crates ...
  Downloaded project v0.1.0 (registry `private-crate`)
   Compiling project v0.1.0 (registry `private-crate`)
   Compiling need_project v0.1.0-0eb85488 (/builds/noa-crates/need_project2/target/package/need_project-0.1.0-0eb85488)
    Finished dev [unoptimized + debuginfo] target(s) in 2.89s
    Packaged 6 files, 4.7KiB (1.8KiB compressed)

Félicitation, vous avez packagé votre version 0.1.0-0eb85488 de need_project et celle-ci peut alors se retrouver dans la package registry de need_project.

Factorisation

Tout cela c’est très bien mais on voit bien que les étapes sont très semblables entre le job de release et de pre-release.

Il doit être possible de mettre en place un système qui permet de factoriser ces répétitions, et ce mécanisme ne provient pas de Gitlab mais du format YAML, lui-même.

Il s’agit des YAML anchors.

Qu’est ce que l’on peut factoriser ?

Tout d’abord les dépendences

.dependencies: &dependencies
  # dépendences
  - apt update && apt install -y yq

Puis la définition de la configuration SSH

.ssh-connexion: &ssh-connexion:
  # configuration SSH
  - mkdir -p ~/.ssh && chmod -R 700 ~/.ssh
  - |
    cat << EOF > ~/.ssh/config 
    Host $CRATE_PACKAGE_ENDPOINT
        User $CRATE_PACKAGE_USER:$CRATE_PACKAGE_TOKEN
        Port $CRATE_PACKAGE_PORT
    EOF
  # création de la paire de clefs
  - ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
  # ajout de la clef publique du proxy
  - ssh-keyscan -p $CRATE_PACKAGE_PORT $CRATE_PACKAGE_ENDPOINT >> ~/.ssh/known_hosts

Ensuite, la récupération des informations du package.

.version: &version
  # récupération des informations du paquet
  - export CRATE_NAME=$(tomlq '.package.name' Cargo.toml  | tr -d '"')
  - export CRATE_VERSION=$(tomlq '.package.version' Cargo.toml  | tr -d '"')
  - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate

Et finalement, le packaging en lui-même

.packaging: &packaging
  # packaging
  - cargo package --allow-dirty
  - cargo metadata --format-version 1 > metadata.json
  - ls target/package/$CRATE_FILE
  # upload
  - 'curl -i --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file target/package/${CRATE_FILE} "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/$CRATE_FILE"'
  - 'curl -i --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file metadata.json "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/metadata.json"'

On peut alors jouer aux légos 🧱


.prepare: &prepare
  - *dependencies
  - *ssh-connexion
  - *version

release-dev:
  image: rust:1.77
  stage: packaging
  # manuel
  when: manual
  # si la branche n'est pas main
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script:
    - *prepare
    # on créé la version flottante
    - export CRATE_VERSION=$CRATE_VERSION-$CI_COMMIT_SHORT_SHA
    - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate
    # On remplace la version
    - tomlq --arg VERSION $CRATE_VERSION -t '.package.version = $VERSION' Cargo.toml > Cargo.toml.modified
    - mv Cargo.toml.modified Cargo.toml
    - *packaging

release-prod:
  image: rust:1.77
  stage: packaging
  # seulement si c'est main
  only:
    - main
  script:
    - *prepare
    - *packaging

C’est quand même plus clean comme ça 😀

.gitlab-ci.yml

stages:
  - packaging

variables:
  # gitlab token
  CRATE_PACKAGE_TOKEN: $CI_JOB_TOKEN
  # l'ID du projet qui supportera les crates par défaut le project du job
  CRATE_PACKAGE_PROJECT_ID: $CI_PROJECT_ID
  # API user
  CRATE_PACKAGE_USER_API: JOB-TOKEN
  # Host du proxy SSH
  CRATE_PACKAGE_ENDPOINT: noa-crates.cleverapps.io
  # Port d'écoute du proxy SSH
  CRATE_PACKAGE_PORT: 22066
  # Utilisateur associé au token
  CRATE_PACKAGE_USER: personal-token

.dependencies: &dependencies
  # dépendences
  - apt update && apt install -y yq

.ssh-connexion: &ssh-connexion
  # configuration SSH
  - mkdir -p ~/.ssh && chmod -R 700 ~/.ssh
  - |
    cat << EOF > ~/.ssh/config 
    Host $CRATE_PACKAGE_ENDPOINT
        User $CRATE_PACKAGE_USER:$CRATE_PACKAGE_TOKEN
        Port $CRATE_PACKAGE_PORT
    EOF
  # création de la paire de clefs
  - ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
  # ajout de la clef publique du proxy
  - ssh-keyscan -p $CRATE_PACKAGE_PORT $CRATE_PACKAGE_ENDPOINT >> ~/.ssh/known_hosts

.packaging: &packaging
  # packaging
  - cargo package --allow-dirty
  - cargo metadata --format-version 1 > metadata.json
  - ls target/package/$CRATE_FILE
  # upload
  - 'curl -i --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file target/package/${CRATE_FILE} "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/$CRATE_FILE"'
  - 'curl -i --header "$CRATE_PACKAGE_USER_API: $CRATE_PACKAGE_TOKEN" --upload-file metadata.json "${CI_API_V4_URL}/projects/${CRATE_PACKAGE_PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/metadata.json"'

.version: &version
  # récupération des informations du paquet
  - export CRATE_NAME=$(tomlq '.package.name' Cargo.toml  | tr -d '"')
  - export CRATE_VERSION=$(tomlq '.package.version' Cargo.toml  | tr -d '"')
  - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate

.prepare: &prepare
  - *dependencies
  - *ssh-connexion
  - *version

release-dev:
  image: rust:1.77
  stage: packaging
  # manuel
  when: manual
  # si la branche n'est pas main
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script:
    - *prepare
    # on créé la version flottante
    - export CRATE_VERSION=$CRATE_VERSION-$CI_COMMIT_SHORT_SHA
    - export CRATE_FILE=${CRATE_NAME}-${CRATE_VERSION}.crate
    # On remplace la version
    - tomlq --arg VERSION $CRATE_VERSION -t '.package.version = $VERSION' Cargo.toml > Cargo.toml.modified
    - mv Cargo.toml.modified Cargo.toml
    - *packaging

release-prod:
  image: rust:1.77
  stage: packaging
  # seulement si c'est main
  only:
    - main
  script:
    - *prepare
    - *packaging

Pour le prochain, article on verra comment gérer le problème épineux des workspaces.

Partie 1: Présentation, Installation du Proxy et action manuelle

2024-04-21T00:00:00+00:00

Les articles de la série

Bonjour à toutes et à tous 😀

crates.io, c’est vraiment bien, c’est une plateforme qui unifie toutes les crates publiques en un seul point.

Mais il est là le souci, crates publiques, dès que l’on veut avoir des crates privées, cela devient plus complexe à cause de l’authentification nécessaire.

Cargo permet au moyen d’un fichier addon .cargo/config.toml, à définir au niveau du projet où du système entier, de spécifier des registries privées en utilisant la nomenclature

.cargo/config.toml

[registries.my-private-registry]
index = "Endpoint URL"

Et peut alors s’utiliser dans un Cargo.toml comme n’importe quelle crate.

Cargo.toml

[package]
#...

[dependencies]
private-crate = {version = "1.0.0", registry = "my-private-registry" }

Et si en plus d’être privée, votre registry nécessite de l’authentification alors vous devez vous bâtir votre propre système de credential provider.

Il existe diverses solutions comme artifactory, kellnr ou s’installer son propre crates.io qui tendent à rapprocher l’expérience de dev la plus proche d’un crates.io classique.

Toutes ces solutions sont cools, mais nécessitent de la maintenance et moi, je suis fainéant. Je ne veux pas à avoir à setup un autre bidule contraignant.

C’est alors que j’ai découvert une solution des plus élégantes, il s’agit de gitlab-cargo-shim, un projet sous licence WTFPL qui fait le juste travail que je lui demande.

Son principe de fonctionnement est fort simple. Gitlab dispose (même en version SaaS) d’une package registry generic. Celle-ci permet au moyen d’appels API authentifiés par token d’accès (personnel, de groupe, de projet, de CI) de venir pousser et télécharger de la données dans un bucket S3.

L’idée est donc de mettre à profit cette API de package registry, pour venir y stocker les fichiers .crate qui sont basiquement des archives de projets.

Profitons de ce backend déjà existant 😄

Le problème est

Comment faire parler cargo en API Gitlab?

Et comme généralement dans ces cas de transitions de protocoles la réponse est : un proxy!

Nous avons donc un proxy qui parle à la fois le “cargo” et le “gitlab” et gitlab parle à son bucket S3.

+--------+     +-------+   +--------+    +----+ 
| Cargo  <-----> Proxy <---> Gitlab <----> S3 | 
+--------+     +-------+   +--------+    +----+

Deuxième problème

Comment authentifier les appels de cargo vers Gitlab?

En effet, pour que le proxy puisse intéragir avec la package registry via un appel API, celui-ci doit comporter le token d’authentification.

Il faut donc réussir à réaliser ceci.

┌───────┐  Token   ┌───────┐  Token  ┌────────┐     
│ Cargo ├──────────► Proxy ├─────────► Gitlab │     
└───────┘   ???    └───────┘   API   └────────┘     
                              HTTPS

La question que l’on doit alors se poser c’est qu’est que l’on met à la place des ???.

Cargo parle plusieurs protocoles:

git
ssh
https

Nous n’allons pas utiliser git car c’est un protocole trop spécialisé pour ce que l’on a besoin de faire, nous ne pouvons pas non plus utiliser https car l’ajout mot de passe dans une URL est très peu recommandé pour des raisons évidentes de sécurité.

Il nous reste SSH.

Mais le problème reste entier, comment transmettre de manière sécurisée le token d’authentification pour l’API Gitlab ?

Et c’est là qu’on peut être extrêment malin.

Lorsque l’on se connecte au travers de SSH on le fait toujours au travers d’un utilisateur, et le format du nom de l’utilisateur n’a pas vraiment de formalisme.

L’idée est donc de faire pareil qu’avec le https.

Mais au lieu de le mettre dans l’URL en clair c’est le protocole SSH qui le transmettra de manière sécurisée une fois le handshake réalisé.

.cargo/config.toml

[registries.my-private-registry]
index = "ssh://personal-token:[TOKEN]@[ENDPOINT]"

Sur le papier c’est bien, sauf que les créateur de cargo n’ont pas fais dans la dentelles sur l’interdiction des mots de passes dans l’URL d’une registry.

Mais c’est là que l’on peut être doublement malin.

SSH vient avec un fichier qui se nomme .ssh/config.

Dedans, il est possible par host de définir des règles à exécuter. Nous tout ce que l’on veut c’est que l’URL reste immaculé de mot de passe mais qu’il soit tout de même transmit.

Le fichier de config à ce pouvoir

.ssh/config

Host ENDPOINT
    User personal-token:TOKEN

Et voilà ! Maintenant le token arrive jusqu’au proxy ! Qui peut alors réaliser en délégation de droits, les calls API sur Gitlab et transmettre les réponses dans le stream SSH.

┌───────┐  Token   ┌───────┐  Token  ┌────────┐    ┌────┐ 
│ Cargo ◄──────────► Proxy ◄─────────► Gitlab ◄────► S3 │ 
└───────┘   SSH    └───────┘   API   └────────┘    └────┘ 
                              HTTPS

Il nous faut maintenant le proxy.

Vous pouvez très bien le faire tourner en local mais j’ai décider de l’héberger chez clever-cloud car cela sera plus pratique pour la suite.

Commençons.

Installons les clever-tools.

npm i -g clever-tools

Je vous conseil une version node 20 d’installé sinon il va râler.

On s’authentifie

clever login

Puis on créé une app une application nodeJS, oui c’est chelou mais comme notre proxy ne parle que SSH, lorsque l’on va venir vérifier si le port HTTP 8080 répond, ça ne marchera pas.

On va donc ruser un peu.

On clone notre proxy

git clone https://github.com/w4/gitlab-cargo-shim.git && gitlab-cargo-shim

Puis on crée l’application

clever create --type node
Your application has been successfully created!
ID: app_bf53be9f-abbc-421d-9a43-c097cfc476e9

Il est possible de définir l’organisation de l’application avec le paramètre --org.

On lie l’application et le dépôt avec

clever link app_bf53be9f-abbc-421d-9a43-c097cfc476e9

On se met dans une branche

git branch clever
git switch clever

On créé un fichier à la racine du projet package.json avec le contenu suivant.

{
    "name": "app",
    "scripts" : {
        "install": "cargo build --release"
    }
}

On commit.

Sur la console on vient rajouter plusieurs variable d’environement:

D’abord CONFIG avec le contenu suivant

## socket address for the SSH server to listen on
listen-address = "[::]:4040"

## directory in which the generated private keys for the server
## should be stored
state-directory = "/home/bas/state"

[gitlab]
## the base url of the gitlab instance
uri = "https://gitlab.com"

Le port 4040 est obligatoire.
Le /home/bas/state permet d’avoir un endroit où l’application a les droits en écritures.
L’ uri est à votre convenance, moi je vais utiliser l’instance SaaS de Gitlab mais vous êtes libre d’utiliser votre instance privée.

Puis qui créé la configuration et lance le binaire

CC_RUN_COMMAND = echo "${CONFIG}" > /home/bas/config.toml && target/release/gitlab-cargo-shim --config /home/bas/config.toml

Qui démarre un serveur HTTP sur le port 8080 en background et répond “OK”

CC_PRE_RUN_HOOK = mkdir -p dist && echo OK > dist/index.html && (python3 -m http.server -d dist 8080)&

Et enfin qui va cacher uniquement le package.json et le binaire à l’issu de l’étape de build, passant de 1Go à 17Mo le cache 😁

CC_OVERRIDE_BUILDCACHE = /package.json:/target/release/gitlab-cargo-shim

Tout l'env en un clic

CC_OVERRIDE_BUILDCACHE="/package.json:/target/release/gitlab-cargo-shim"
CC_PRE_RUN_HOOK="mkdir -p dist && echo OK > dist/index.html && (python3 -m http.server -d dist 8080)&"
CC_RUN_COMMAND="echo \"${CONFIG}\" > /home/bas/config.toml && target/release/gitlab-cargo-shim --config /home/bas/config.toml"
CONFIG="## socket address for the SSH server to listen on
listen-address = \"[::]:4040\"

## directory in which the generated private keys for the server
## should be stored
state-directory = \"/home/bas/state\"

[gitlab]
## the base url of the gitlab instance
uri = \"https://gitlab.com\""

Je vous conseille également d’activer l’utilisation d’une instance de build dans Information -> Enable dedicated build instance, et de la passer en XL si vous ne voulez pas mourrir d’ennuie en attendant le build.

Votre instance de run peut rester une XS.

Vous pouvez également lui ajouter un domain perso. Moi ça sera noa-crates.cleverapps.io.

Finalement activez la redirection tcp

clever tcp-redirs add --namespace cleverapps

Vous allez obtenir un numéro de port, c’est celui-ci qui sera redirigé vers le port 4040 de notre proxy SSH.

Successfully added tcp redirection on port: 22066

On configure le .ssh/config.

Host noa-crates.cleverapps.io
    User personal-token:TOKEN
    Port 22066

Vous pouvez maintenant déployer

clever deploy

Après plusieurs minutes de build, votre app est up and running et prête à recevoir du SSH.

ssh noa-crates.cleverapps.io

Cela prend un certain temps et non ce n’est pas encore la faille xz qui ralenti la connexion, mais simplement le trajet très étendu qui fait un call sur Gitlab.

En effet voici la réponse

Hi there, Akanoa! You've successfully authenticated, but gitlab-cargo-shim does not provide shell access.
Connection to noa-crates.cleverapps.io closed.

Le Akanoa est une information connu de seul Gitlab, ce qui prouve à la fois que le SSH répond mais aussi que le proxy utilise bel et bien mon token pour opérer sur Gitlab!! 🤩

Et donc comment pouvons nous utiliser notre système avec cargo ?

Déjà nous ne ferons pas de cargo publish, il est trop opiniated et va nous géner.

Par contre, nous pouvons décomposer ses étapes pour créer notre flux de commandes.

Testons à partir d’un projet vide.

cargo init project --lib && cd project

On lance d’abord un

cargo package --allow-dirty

--allow-dirty permet de ne pas à avoir à committer les modifications

Cela créé un fichier target/package/project-0.1.0.crate.

Dedans on y trouve seulement une archive de notre projet.

tar -tvf target\package\project-0.1.0.crate
-rw-r--r--  0 0      0         545 janv. 01  1970 project-0.1.0/Cargo.toml
-rw-r--r--  0 0      0          78 nov. 29  1973 project-0.1.0/Cargo.toml.orig
-rw-r--r--  0 0      0         216 nov. 29  1973 project-0.1.0/src/lib.rs

On génère également un manifeste qui contient tout de sorte de métadonnées.

cargo metadata --format-version 1 > metadata.json

Je ne le mets pas en entier ici, mais il contient la résolution de l’arbre de dépendances du projet et d’autres informations dont une représentation du Cargo.toml dans notre archive.

Ok, et maintenant, on fait comment pour l’envoyer sur Gitlab ?

Et bien c’est simple: curl 😄 Et je ne déconne même pas. Nous allons utiliser l’API de Gitlab comme elle doit être utilisée.

Mais d’abord, il nous faut un projet.

On en créé un sur Gitlab et on récupère le project ID qui se trouve dans les 3 points verticaux en haut à droite ⋮.

Ici ça sera 57111774.

Vérifiez bien que dans les paramètres du projet dans /settings/packages_and_registries, que le “Number of duplicate assets to keep” est bien à 1 !

TOKEN=[votre token]
PROJECT_ID=57111774
CRATE_NAME=project
CRATE_VERSION=0.1.0
CRATE_FILE=$CRATE_NAME-$CRATE_VERSION.crate
ENDPOINT=https://gitlab.com/api/v4
curl --header "PRIVATE-TOKEN: $TOKEN" --upload-file target/package/${CRATE_FILE} "${ENDPOINT}/projects/${PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/$CRATE_FILE"
curl --header "PRIVATE-TOKEN: $TOKEN" --upload-file metadata.json "${ENDPOINT}/projects/${PROJECT_ID}/packages/generic/${CRATE_NAME}/${CRATE_VERSION}/metadata.json"

Ici cela donne

curl --header 'PRIVATE-TOKEN: ***REDACTED***' --upload-file target/package/project-0.1.0 https://gitlab.com/api/v4/projects/57111774/packages/generic/project/0.1.0/project-0.1.0.crate
curl --header 'PRIVATE-TOKEN: ***REDACTED***' --upload-file metadata.json https://gitlab.com/api/v4/projects/57111774/packages/generic/project/0.1.0/metadata.json

Si vous vous dirigez dans la package registry du projet vous verrez que le paquet project-0.1.0 est bien présent et dedans vous pourrez apercevoir le project-0.1.0.crate.

Et maintenant comment ça s’utilise dans un projet qui a bien de project-0.1.0 ?

Pas du curl quand même ???

Non, non, on va enfin utiliser le proxy ^^

On se créé un nouveau projet

cargo init need_project

Puis on créé le

.cargo/config

[registries.private-crate]
index = "ssh://[proxy endpoint]/[path project]"
[net]
git-fetch-with-cli = true

Attention à ne pas oublier le net.git-fetch-with-cli = true, sinon rien ne marche !!

Pour moi proxy endpoint sera “noa-crates.cleverapps.io”. Il faut simplement qu’il corresponde au HostName de votre .ssh/config.

Le path project est celui de votre projet gitlab qui possède la package registry. Moi ça sera “noa-crates/project”.

Ce qui me donne

.cargo/config

[registries.private-crate]
index = "ssh://noa-crates.cleverapps.io/noa-crates/project"
[net]
git-fetch-with-cli = true

Ensuite on utilise la dépendence classiquement

.cargo/config.toml

[package]
# ...

[dependencies]
project = {version="0.1.0", registry="private-crate"}

Si on build

cargo build
   Compiling project v0.1.0 (registry `private-crate`)
   Compiling need-project v0.1.0 (/data/need-project)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.95s

On voit que la dépendence project v0.1.0 a bien été tirée.

Notre package registry fonctionne 😁

Dans le prochain article on verra comment industrialiser tout ça ^^