web-dev-qa-db-fra.com

Comprendre les balises CI Gitlab

J'ai lu de la documentation, des articles et vous pourriez m'appeler idiot, mais c'est la première fois que je travaille avec un concept comme celui-ci.

  • J'ai inscrit un coureur avec le tag "test"
  • tag créé "test" dans gitlab
  • lié ce coureur, avec un projet particulier
  • J'ai également ajouté la même étiquette, par exemple "tester" dans mon dépôt local.

MAIS dans quelle mesure l'exécution de mes tâches dépend-elle de ces balises? Toutes ces opérations sont-elles nécessaires? Si je transfère du nouveau code vers le repo, le fichier * .yml est exécuté de toute façon dans la mesure où j'ai déjà testé.

Et alors, si je veux lancer la construction seulement quand je définis une version dans un commit?

IDK ...

   git commit --tags "v. 2.0" -m "this is version 2.0" (probably not right)

Mais bien sûr, cela devrait être universel, donc je n'ai pas toujours besoin de savoir quelle balise utiliser pour déclencher le coureur, mais par exemple le laisser reconnaître les valeurs numériques.

Comme vous pouvez le constater, je suis assez confus ... Si vous pouviez expliquer le fonctionnement exact des balises, je serais donc très reconnaissant de pouvoir comprendre le concept.

18
RiddleMeThis

Les étiquettes pour GitLab CI et les étiquettes pour Git sont deux concepts différents.

Lorsque vous écrivez votre .gitlab-ci.yml, vous pouvez spécifier certains travaux avec la balise testing. Si un coureur auquel cette balise est associée est disponible, il reprend le travail.

Dans Git, dans votre référentiel, les balises sont utilisées pour marquer un commit spécifique. Il est souvent utilisé pour tag une version.

Les deux concepts peuvent être mélangés lorsque vous utilisez des balises (dans Git) pour démarrer votre pipeline dans GitLab CI. Dans votre .gitlab-ci.yml, vous pouvez spécifier la section only avec tags.

Reportez-vous à documentation GitLab pour les tags et niquement .

Un exemple est lorsque vous poussez un tag avec git:

$ git tag -a 1.0.0 -m "1.0.0"
$ git Push Origin 1.0.0

Et un travail dans .gitlab-ci.yml comme ça:

compile:
    stage: build
    only: [tags]
    script:
        - echo Working...
    tags: [testing]    

commencerait à utiliser un coureur avec la balise testing.

À ma connaissance, ce qui manque dans vos étapes est de spécifier la balise testing à votre coureur. Pour ce faire, allez dans GitLab dans votre projet. À côté de Wiki , cliquez sur Paramètres . Allez sur Pipelines CI/CD et vous avez votre (vos) coureur (s). À côté de Guid, cliquez sur l'icône du stylo. Sur la page suivante, les étiquettes peuvent être modifiées.

38
elbaid

Toutes ces opérations sont-elles nécessaires?

Non, si vous n'avez qu'un seul coureur, ou si vous en avez beaucoup mais ne vous souciez pas du coureur qui exécute votre travail, il est alors inutile de baliser les coureurs/travaux.

Alors que se passe-t-il si je veux exécuter build uniquement lorsque je définis une version dans un commit?

job:
  only:
    - tags
3
Ahmad Abdelghany