Loading search data...

Créer des release avec Gitlab

Dans le cadre de l'automatisation du build et de l’intégration continue, je vous propose de voir comment générer des releases dans un CI GitLab.

Depuis peu, il est possible de le générer avec le mot réservé release, mais je vous recommande de plutôt d’utiliser l’API pour créer des versions. En effet, l’api de création d’une release est plus complète et permet notamment d’enregistrer des liens vers d’autres artefacts, comme les binaires stockés dans nexus.

Creation d’une release dans l’interface de Gitlab

Pour comprendre ce qu’est une release je vous propose dans un premier temps de le faire dans l’interface. Seuls les utilisateurs avec des autorisations de développeur ou plus peuvent créer des versions:

gitlab release notes gitlab release notes

  • Cliquez sur Project Overview > Releases
  • Cliquez sur le bouton New Release
  • Vous pouvez soit créer un nouveau tag, soit l’associer en le choisissant à partir de la liste Create From.
    • Si vous créez un nouveau tag, ouvrez la liste déroulante Create From, sélectionnez une branche, une balise ou un commit SHA à utiliser lors de la création du nouveau tag.
  • Vous pouvez y associer des milestones
  • Dans la partie links vous pouvez ajouter des liens vers d’autres artefacts.
  • Cliquez sur le bouton Create Release pour enregistrer votre release.

Destruction d’une release

On ne peut pas détruire une release directement, pour cela il faut tout simplement détruire le tag associé.

Création d’une release dans votre CI Gitlab

Il existe deux moyens de créer une release dans le ci :

  1. via le mot réservé release
  2. via un appel à l'api de gitlab

Création d’une release avec le mot réservé

Moins complet que l’appel api, le mot réservé release, permet de creér des releases mais sans liens vers des artefacts.

Exemple:

ios-release:
  script:
    - echo 'iOS release job'
  release:
    tag_name: v1.0.0-ios
    description: 'iOS release v1.0.0'

release:tag_name Vous devez spécifier un tag pour votre release. Elle peut faire référence à un tag existant ou vous pouvez en créer un nouveau. Lorsque le tag spécifié n’existe pas dans le référentiel, un nouveau est créée à partir du SHA associé du pipeline.

job:
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: 'Release description'

release:description Il est possible de créer une gitlab release note soit en renseignant ce champ soit en indiquant le chemin d’un fichier markdown.

job:
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: './path/to/CHANGELOG.md'

release:ref Si le tag n’existe pas encore, la version est créée à partir de cette ref.

job:
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: './path/to/CHANGELOG.md'
    ref: ${CI_COMMIT_SHORT_SHA}

release:milestones Le titre de chaque jalon auquel la version est associée.

release:released_at La date et l’heure auxquelles la version est prête. Par défaut, la date et l’heure actuelles si elles ne sont pas définies. Doit être mis entre guillemets et exprimé au format ISO 8601.

Exemple complet:

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  script:
    - echo 'running release_job'
  release:
    name: 'Release $CI_COMMIT_TAG'
    description: 'Created using the release-cli $EXTRA_DESCRIPTION'
    tag_name: '$CI_COMMIT_TAG'
    ref: '$CI_COMMIT_TAG'
    milestones:
      - 'm1'
      - 'm2'
      - 'm3'
    released_at: '2020-07-15T08:00:00Z'

Création d’une release via un appel API

Il suffit de remplacer le mot réservé par un appel à l’api comme ceci:

release_job:
  stage: release
  tags:
    - release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  dependencies:
    - build
  script:
    - apk add curl
    - echo 'running release_job for ${TAG}'
    - |
      curl --data "{
        \"tag_name\": \"${TAG}\",
        \"name\": \"${TAG}\",
        \"ref\": \"${CI_COMMIT_SHORT_SHA}\",
        \"description\": \"## CHANGELOG\r\n\r\n- Remove limit of 100 when searching \",
        \"assets\": {
            \"links\": [
              {
                \"name\": \"binaries.${TAG}.tar.gz\",
                \"url\": \"https://myrepo/repository/repo1/binaries.${TAG}.tar.gz\",
                \"filepath\": \"/binary\",
                \"link_type\":\"package\"
              }
            ]
          }
        }" \
        --header "Content-Type: application/json" \
        --header "Private-Token: ${PRIVATE_TOKEN}" \
        --request POST "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/releases"      

Il faut au préalable créer un private TOKEN.

La définition de l’api se trouve ici


Alimenter un blog comme celui-ci est aussi passionnant que chronophage. En passant votre prochaine commande (n'importe quel autre article) via ce lien, je recevrai une petite commission sans que cela ne vous coûte plus cher. Cela ne me permet pas de gagner ma vie, mais de couvrir les frais inhérents au fonctionnement du site. Merci donc à vous!

Mots clés :

devops, tutorials, gitlab, ci-cd,

Autres Articles