🎈 Publication automatique de ğcli

[HugoTrentesaux]

D’après le modèle de bounty

Titre	Publication automatique de ğcli
Lien	https://git.duniter.org/clients/rust/gcli-v2s/-/issues/16
Émetteur	@HugoTrentesaux
Montant estimé	200 DUĞ1
Montant validé	[…]
Attribué à	???

L’intérêt de ĞCli est d’être un utilitaire versatile facile à utiliser et “clé en main” dans lequel on peut ajouter des nouvelles fonctionnalités ou corriger des bugs rapidement. Cela implique de pouvoir publier rapidement des mises-à-jour sans que l’utilisateur ait à recompiler le programme. Voici les fonctionnalités :

• déclencher automatiquement la compilation de ğcli suite à une opération simple comme un tag git par exemple avec la CI GitLab
• publier automatiquement le binaire compilé sur une plateforme de confiance comme par exemple le registry GitLab
• (optionnel) ajouter une commande gcli update pour que gcli se mette à jour automatiquement (et optionnellement gcli update --version 3.1.4)

Commentaire : Je ne souhaite pas forcer l’utilisation de la CI GitLab pour laisser libre cours aux autres solutions qui peuvent exister (webhook et scripts exécutés sur une autre machine qu’un gitlab runner…). Il faut quand même que la solution soit reproductible et raisonnablement sécurisée. Ne pas hésiter à demander plus d’informations et négocier le montant avant de se lancer

[Moul]

L’objectif est de publier, lorsqu’un tag protégé est publié, une release sur Releases · clients / Rust / Ğcli-v2s · GitLab contenant l’exécutable construit dans le job précédent ?

[HugoTrentesaux]

@vit

Pour Sakia, on a utilisé le mot-clefs artifacts/path :

• Générer le fichier dans un dossier du projet (ici ci/appimage).
• Indiquer le chemin du fichier dans le projet à la CI avec artifacts/path.

release_appimage:
  extends:
    - .changes
  stage: release
  when: manual
  script:
    - pip install -r requirements.txt
    - pip install -r requirements_deploy.txt
    - make build
    - make appimage
  artifacts:
    paths:
      - ci/appimage/Sakia_x86_64.AppImage

Le fichier devrait apparaître dans Release…

Je connaissais pas cette instruction “artifacts”, je vais essayer.

[vit]

C’est une liste donc tu peux mettre plusieurs fichiers si tu le souhaites.

  artifacts:
    paths:
      - ci/appimage/Sakia_x86_64.AppImage
      - build/target/my_executable.exe

[HugoTrentesaux]

En fait j’utilisais déjà ce mot clé artifacts dans ma tentative de CI pour ğcli : .gitlab-ci.yml · master · clients / Rust / Ğcli-v2s · GitLab

Mais ce qui me manque c’est l’étape pour faire une page de release avec le lien vers le binaire. J’ai l’impression que ça ne fait pas partie du vocabulaire de gitlabci et qu’il faut utiliser un autre outil pour soumettre une page comme le fait le cargo xtask release-runtime sur Duniter. Mais j’ai pas envie de tout redévelopper, je veux juste une solution simple, et idéalement quelqu’un qui s’en occupe parce que ce n’est pas mon dada

Il y a toujours ma tentative WIP try to release with CI (5ba8cbc7) · Commits · clients / Rust / Ğcli-v2s · GitLab mais ça n’a pas abouti et je n’ai pas envie de remettre le nez dedans.

On peut toujours télécharger les artefacts directement https://git.duniter.org/clients/rust/gcli-v2s/-/jobs/125527/artifacts/raw/target/release/gcli?inline=false mais c’est pas pratique

[poka]

@HugoTrentesaux

Mais j’ai pas envie de tout redévelopper, je veux juste une solution simple, et idéalement quelqu’un qui s’en occupe parce que ce n’est pas mon dada

On est en 2024:

#!/bin/bash

# Vérifiez si le token d'accès privé GitLab est défini
if [ -z "$GITLAB_PRIVATE_TOKEN" ]; then
    echo "Token d'accès privé GitLab non défini. Arrêt du script."
    exit 1
fi

# Variables
PROJECT_ID="604"
RELEASE_NAME="Release $CI_COMMIT_TAG"
RELEASE_DESCRIPTION="Description de la release $CI_COMMIT_TAG"
ARTIFACT_PATH="target/release/gcli"
GITLAB_API_URL="https://git.duniter.org/api/v4"

# Création de la release
echo "Création de la release $RELEASE_NAME..."
curl --header "PRIVATE-TOKEN: $GITLAB_PRIVATE_TOKEN" \
     --data "name=$RELEASE_NAME&tag_name=$CI_COMMIT_TAG&description=$RELEASE_DESCRIPTION" \
     "$GITLAB_API_URL/projects/$PROJECT_ID/releases"

# Construction de l'URL de l'artéfact
ARTIFACT_URL="$CI_PROJECT_URL/-/jobs/artifacts/$CI_COMMIT_TAG/raw/$ARTIFACT_PATH?job=build"

# Ajout de l'artéfact à la release
echo "Ajout de l'artéfact à la release..."
curl --header "PRIVATE-TOKEN: $GITLAB_PRIVATE_TOKEN" \
     --data-urlencode "url=$ARTIFACT_URL" \
     --data-urlencode "name=$(basename $ARTIFACT_PATH)" \
     "$GITLAB_API_URL/projects/$PROJECT_ID/releases/$CI_COMMIT_TAG/assets/links"

echo "Script terminé."

image: "rust:latest"

stages:
  - build
  - release

build:
  stage: build
  script:
    - cargo build --release
  artifacts:
    paths:
      - target/release/gcli
  cache:
    key:
      files:
        - Cargo.lock
    paths:
      - target/release
  only:
    - tags

release:
  stage: release
  image: rust
  script:
    - chmod +x .ci/release_script.sh
    - .ci/release_script.sh
  only:
    - tags
  dependencies:
    - build

• Variables d’Environnement : GITLAB_PRIVATE_TOKEN doit être défini dans les variables CI/CD de votre projet GitLab. Ce token doit avoir les permissions nécessaires.
• Placement du Script : Le script release_script.sh doit être placé dans le répertoire .ci/ de votre dépôt Git et doit être rendu exécutable.

[HugoTrentesaux]

Oui, bah il faut utilise GPT pour générer le contenu de release-script.sh maintenant. Mais ça m’aurait arrangé que Gitlab intègre ça à son format .yml pour qu’on n’ait pas à écrire un script avec curl par exemple. Ou release-cli comme j’ai essayé de le faire ici.

[poka]

Je suis bien d’accords c’est bizarre de devoir passer par l’API gitlab.
Le contenu du script release-script.sh est présent dans mon message.

[poka]

Du coup j’ai droit aux 200DU/ğ1 ?

[HugoTrentesaux]

Oui, si tu fais la MR et que ça marche.

[poka]

@poka

  only:
    - tags

Voilà: Releases · clients / Rust / Ğcli-v2s · GitLab

J’ai juste ajouté une condition au début pour bien verrouiller mais c’est tout:

if [ -z "$CI_COMMIT_TAG" ]; then
    echo "This script should only be run on a tag."
    exit 1
fi

[HugoTrentesaux]

Et voilà, c’est un bounty gagné par poka ! Releases · clients / Rust / Ğcli-v2s · GitLab

la release est awesome, mais il va falloir attendre le réseau de test pour la tester ! elle s’appuie sur la dernière version du runtime (mais pas encore sur la dernière version de duniter-squid, j’attends qu’on finisse !4 pour ça)

@Tchois, est-ce que tu voudrais bien gérer le paiement des bounty en Ğ1 ? (cf le tag bounty)

[poka]

Ah oui et je suis l’auteur de la release car c’est moi qui ai fait le jeton d’accès, il faudrait le générer avec un autre compte plus légitime, le tiens ou je ne sais pas si il y a un user gitlab ?

---

Si apparemment il y a 4, dont 3 n’ont jamais été utilisés. Je pense qu’il faudrait créer un user juste pour ça, et lui donner les droits nécessaires sur le dépôt. Ca éviterait d’utiliser un token admin.

[Tchois]

@HugoTrentesaux

@Tchois, est-ce que tu voudrais bien gérer le paiement des bounty en Ğ1 ?

Bon j’ai pas trop compris ce que c’est qu’un bounty, moi j’étais resté à la barre chocolaté (est-ce que j’ai la bonne référence? ).
Et c’est pas la dernière discussion sur les drapeaux qui m’a aidé .
Si tu veux on en parle ce week-end, on trouvera bien 5mn, pour que j’en sache plus.

[poka]

un bounty c’est une prime.

[vit]

Si je trouve une solution plus simple, je récupère le bounty ou pas (j’adore les bounty, même si la noix de coco se coince entre les dents…).

J’ai fait une recherche sur l’historique du .gitlab-ci.yml de Sakia et Tikka. Et j’ai utilisé aussi la technique de @Poka pour publier une version compilée de Tikka. Mais les commandes API Gitlab servaient à transférer l’artefact que je stockais dans la registry de GitLab. Un système compliqué que j’ai abandonné.

De mémoire, une Release est créé automatiquement lorsqu’on crée un Jalon (Milestone). En cherchant un peu dans la doc, j’ai découvert le mot clef release. J’ai l’impression qu’on peut cumuler les mots clefs artifacts et release dans la CI.

Tant que le sujet est chaud, @poka tu peux peut-être ne plus faire appel à l’API avec ces exemples :

Release CI/CD examples | GitLab

Hope it helps !

[poka]

@vit

Si je trouve une solution plus simple, je récupère le bounty ou pas

hey non j’ai même rajouter une MR avec une commande gcli pour publish automatiquement le tag avec la bonne version: Add publish command (!19) · Merge requests · clients / Rust / Ğcli-v2s · GitLab

Et si tu espères avoir la moindre chance de voir le bout de ce bounty, il faut que tu fasses la MR et que ça marche.
Mais j’y crois pas parceque ce bounty, il est à moi, j’en ai chier pour l’obtenir, à la sueur de mon gpt.

[poka]

Et voilà j’ai ajouté un commit qui fait exactement ce que tu proposes : add vit proposition to publish artefact without gitlab API (de184b29) · Commits · clients / Rust / Ğcli-v2s · GitLab

J’ai été plus rapide que toi, il fallait le faire toi même si tu voulais me voler mon bounty. C’est con hein ? J’espère que ça marche pas comme ça j’aurais pas fait mon script pour rien.

[poka]

Bon et bien je dois l’avouer, @vit avait raison, je m’avoue vaincu
La dernière version de la CI dans ma dernière MR permet de parfaitement publié la release avec son artefact: Releases · clients / Rust / Ğcli-v2s · GitLab

Je me suis également permis d’ajouter les derniers commits depuis la dernière release en desciption.
Le tout, sans utilisation de l’api gitlab, et sans même besoin de script bash externe.

Voici ce que ça donne en définitif dans le .gitlab-ci.yml: .gitlab-ci.yml · add-publish-command · clients / Rust / Ğcli-v2s · GitLab

De ce fait et par ma grande bonté, j’accepte exceptionnellement de partager mon avec @vit ici présent, en gage de reconnaissance pour sa remarque ayant déjoué le cours de l’histoire toute entière.

[vit]

Je te laisse le bounty la gloire et les filles. Tu as fait tout le boulot plusieurs fois ! Tu as l’humilité des sages qui se remettent en question, tu mérites largement plus que moi d’avoir de la noix de coco coincée entre les dents !

Félicitations, et je suis heureux d’avoir modestement donné une piste d’amélioration.

Tout seul on va plus vite, mais ensemble on est plus forts !