web-dev-qa-db-fra.com

Gitlab CI utilisant des badges pour chaque travail

Disons que j'ai configuré plusieurs tâches pour un projet comme suit:

build_win32:
  script: ...

build_ios:
  script: ...

unit_tests:
  script: ...

server_tests:
  script: ...

client_tests:
  script: ...

Ce que je veux réaliser est de configurer les badges pour chaque travail sous README.md afin que je puisse avoir un retour immédiat sur la partie qui a mal tourné.

Il existe un Documentation Gitlab on sur la définition des badges, mais sa limitation montre comment configurer les badges pour build et coverage status uniquement.

Je me demande s'il existe une telle fonctionnalité intégrée dans Gitlab CI. Je pourrais aussi utiliser des plugins tiers. Toute aide sera appréciée.

gitlab-cibadge
8
Matt

Vous pouvez obtenir ce dont vous avez besoin en créant des badges dans vos étapes de pipeline, en enregistrant les fichiers de badge en tant qu'artefacts de pipeline et en les publiant sur GitLab Pages. De là, vous pouvez référencer les badges dans votre README.md

Comment faire ce que vous avez demandé

1. Générez le badge

Dans chacune de vos étapes de CI, vous devez générer des fichiers de badge et les stocker sous public/<badge-file>.svg.

Vous pouvez générer des fichiers de badge à l’aide de http://shields.io . J'ai écrit mon propre générateur de badges Python, que l'on peut trouver ici: https://github.com/jongracecox/anybadge

2. Enregistrer le badge en tant qu'artefact de pipeline

Enregistrez chaque fichier de badge généré en tant qu'artefact dans le travail de CI en l'incluant dans chaque travail dans le .gitlab-ci.yml:

build_win32:
  script: ...
    - <generate public/build_win32.svg>
  artifacts:
    paths:
      - public/build_win32.svg

build_ios:
  script: ...
    - <generate public/build_ios.svg>
  artifacts:
    paths:
      - public/build_ios.svg

unit_tests:
  script: ...
    - <generate public/unit_tests.svg>
  artifacts:
    paths:
      - public/unit_tests.svg

server_tests:
  script: ...
    - <generate public/server_tests.svg>
  artifacts:
    paths:
      - public/server_tests.svg

client_tests:
  script: ...
    - <generate public/client_tests.svg>
  artifacts:
    paths:
      - public/client_tests.svg

3. Publier un badge sur GitLab Pages

Inclure une nouvelle étape de publication pages, qui déploie tout le contenu du répertoire public sur les pages GitLab :

pages:
  stage: deploy
  artifacts:
    paths:
    - public
  only:
  - master

Vous ne devriez pas avoir besoin de modifier ce qui précède. Une fois ce travail exécuté, tous les fichiers de public seront disponibles via le serveur Web des pages GitLab. C'est souvent http://NAMESPACE.GITLABPAGESSERVER/project

En savoir plus sur les pages GitLab ici: https://docs.gitlab.com/ce/user/project/pages/index.html

4. Inclure les badges dans README.md

Lorsque le pipeline principal est exécuté pour le projet, les fichiers de badge sont publiés dans GitLab Pages et peuvent ensuite être référencés à partir du projet README.md.

Pourquoi ceci pourrait ne pas avoir de sens

Je comprends pourquoi vous posez cette question, mais je voudrais expliquer pourquoi vous ne voudriez peut-être pas le faire.

Les pipelines GitLab fonctionnent à chaque poussée dans le projet, dans chaque branche. Généralement, vous souhaitez uniquement générer des badges pour votre fichier README à partir de la branche master (ou d'une version), de sorte que vous limitez le pas de pages à ne s'exécuter que sur master@group/project .

Notez également qu'un pipeline sera généralement configuré pour s'arrêter en cas d'erreur de travail. Cela signifierait que si un travail de pipeline principal échouait, les badges de ce pipeline ne seraient pas générés et ne seraient donc pas utiles pour déterminer le travail ayant échoué.

Le meilleur endroit pour obtenir vos commentaires immédiats est la vue pipeline, et vous pouvez ajouter le badge de succès du pipeline à votre fichier Lisez-moi avec un lien vers le pipeline, généralement quelque chose comme https://gitlabserver/namespace/project/badges/branch/build.svg.

Si vous souhaitez toujours utiliser l'approche que vous avez décrite, ma suggestion serait de définir chaque étape du pipeline sur autoriser l'échec . Cela permettrait au pipeline complet de s'exécuter, malgré les échecs d'un travail, et les badges devraient toujours être générés et publiés sur Pages.

9
JGC

Vous pouvez suivre les étapes de JGC, mais au lieu de déployer le badge sur le répertoire public d'une page Gitlab, vous pouvez créer un lien direct vers le dernier artefact de construction.

Par exemple, l'URL suivante renvoie à un badge pylint créé avec anybadge et téléchargé comme artefact.

https: //gitlabserver/namespace/project/-/jobs/artifacts/master/raw/public/pylint.svg? job = test

5
jcgiret

Je préfère utiliser une branche temporaire pour stocker des badges entre différents travaux ci-dessus.

Vous pouvez trouver un exemple de projet détaillé montrant comment utiliser les badges par travail en utilisant une branche temporaire avec GitLab ici: https://gitlab.version.fz-juelich.de/vis/jusense-cicd

Et sa documentation ici: https://gitlab.version.fz-juelich.de/vis/jusense-cicd/wikis/Continuous-Integration-and-Delivery

Mais quelle que soit la stratégie que vous préférez, les badges personnalisés ne sont jusqu'à présent pas pris en charge correctement dans GitLab. Vérifiez cette question pour plus de détails: ont créé un problème sur GitLab pour cela: https://gitlab.com/gitlab-org/gitlab-ce/issues/50603

3
j.goebbert

J'ai développé une solution de contournement pour les badges en temps réel par tâche . Elle peut être facilement modifiée.

L'exemple de repo: ci-test/badges . Il y a aussi une procédure complète, je ne vais donc pas le copier-coller ici.

L'idée principale est (en supposant que vous occupiez maintenant un poste en cours):

  • Récupérez un badge sur le Web dans un fichier.
  • Téléchargez le fichier de badge sur un stockage en temps réel à partir duquel il peut être lié (par exemple Dropbox).

Dropbox prend en charge l’appel de son API via des requêtes HTTP (voir this ) . Ainsi, tout ce qui précède peut être effectué à l’aide, par exemple, de Requêtes curl ou Python - outils de base . Il vous suffit de transmettre le jeton d'accès Dropbox en tant que variable secrète et d'enregistrer le fichier sous le même nom pour écraser l'ancien badge.

Ensuite, vous pouvez lier directement le badge Dropbox là où vous en avez besoin. Il y a quelques astuces. Assurez-vous donc de consulter mon exemple de dépôt si vous souhaitez l'utiliser. Pour moi, cela fonctionne assez bien et semble bien fonctionner. sois rapide.

L'avantage de cette méthode est que vous n'avez pas à vous soucier de GitLab Pages . Au lieu de publier sur Pages, vous le mettez dans Dropbox . Il s'agit d'un simple transfert de fichier appelé par requête HTTP . Non. plus à cela.

2
kubouch