Rajouter de l'autotag sur le gitlab

Dev
1

Bonjour,

Plusieurs fois on voit des commit build mais pas de pose du tag ensuite et on oublie.

Est ce que l’on pourrait dans les CI faire par exemple :

stages:
  - build
  - tag

build:
  stage: build
  script:
    - echo "build ok"

tag:
  stage: tag
  needs: ["build"]
  only:
    - main
  script:
    - echo "Commit message: $CI_COMMIT_MESSAGE"

    # Vérifie que le commit commence par 'build'
    - |
      if [[ ! "$CI_COMMIT_MESSAGE" =~ ^build ]]; then
        echo "Commit does not start with 'build' -> skip tag"
        exit 0
      fi

    # extrait version X.Y.Z
    - VERSION=$(echo "$CI_COMMIT_MESSAGE" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+')

    - |
      if [ -z "$VERSION" ]; then
        echo "No version found -> skip tag"
        exit 0
      fi

    - echo "Version found: $VERSION"

    # config git
    - git config user.email "ci@gitlab"
    - git config user.name "gitlab-ci"

    # récupère les tags existants
    - git fetch --tags

    # vérifie si le tag existe
    - |
      if git rev-parse "$VERSION" >/dev/null 2>&1; then
        echo "Tag already exists -> skip"
        exit 0
      fi

    - echo "Create tag $VERSION"

    - git tag "$VERSION"

    - git push https://gitlab-ci-token:${CI_JOB_TOKEN}@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git "$VERSION"
2

Intéressant, et je partage le constat (même si ça peut ou a pu m’arriver).

Si je comprends bien, ça crée un tag x.y.z si la chaîne « x.y.z » est trouvée dans le log de commit et que le tag n’existe pas.
Il manque un test sur la présence de « build » en tout début de log, ou bien cette config le teste aussi ? (je n’ai pas une grosse connaissance des configs de CI)

Est ce qu’on aurait des risques de faux positifs ? Les logs qui commencent par build sont toujours très courts, peu de risque à mon avis.

Peut-être on pourrait mettre ça en test sur spip-contrib-extensions ?

3

en effet j’ai amélioré le code avec un test sur build

je le pause ici mais je nais pas trop ou le mettre car je ne sais pas ou sont rangé les CI sur le gitlab

4

personnellement j’utilise spip-contrib-outils / Spip Releases · GitLab pour gérer le changelog + le up de xyz + la pose du tag

5

Oui mais faut le passer à la main, je cherche une solution par CI pour que ce soit propre et partout

6

Perso je ne suis pas très chaud, mais si la majorité pense que ça vaut le coup je ne râlerai pas.

Si jamais c’est testé, je pense qu’il faudrait le faire sur un seul repo au lieu de tout l’orga qui compte plusieurs centaines de plugins :wink:

7

oui bien sûr, je ne pensais pas le mettre en complet pour le début

8

Pour un néophyte, je comprends que le tag est généré automatiquement si le message de Commît commence par un build ? Si c’est ça, ça me paraît pas mal, sinon j’ai rien compris :wink:

9

exactement, ce qui évite de venir sur le gitlab poser le tag ou une commande de plus
plein de tag ne sont pas poser au fil de l’eau

1 « J'aime »
10

Ça peut sembler magique mais ça ne sera pas miracle car d’une certaine manière c’est passer de « penser à mettre un tag » à « penser un mettre un build »…

11

Oui je sais bien.

Bon je sens que c’est un sujet clos

12

Et comment est-ce clos ?

Pour moi ça ne sera pas une aide car ma géométrie neuronale me rend imperméable aux conventional commits, mais je pense/j’imagine que tous les adeptes de ce formalisme peuvent apprécier un tel automatisme.

13

Ce n’est pas qu’une question de conventional commit, en fait.

C’est assez limitant en cas d’erreur ou d’oubli, par exemple. Si on oubli un ; quelque part et qu’il faut re-release, éventuellement effacer le tag, refaire un truc de commit sans vexer le script de CI, c’est chaud …

D’autre part, c’est remplacer un truc obligatoire par un autre, comme tu dis. Et appliquer ça au 1000+ projets git communautaire, ça me semble un pas un peu trop grand. Il faudra peut-être enfin envisager de créer des organisations où des plugins et des mainteneureuses sont ok pour appliquer des règles communes. Ex: plugins d’e-commerce, plugins de gestion de formulaires, collection de plugins sans aucune règles de dev … et déplacer les plugins existants correspondants de spip-contrib-extensions dans ces nouvelles organisations, avec les mainteneureuses correctement identifiées.

Bref, une chose est sûre, spip-releases fait se genre de boulot plutôt bien, c’est à la main des dev/mainteneureuses, c’est responsabilisant, a contrario de ce genre de scripts que je trouve aussi « trop magique ».