Créer des releases avec Gitlab CI/CD

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

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 :

via le mot réservé release
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 ↗

Maj: Attention suite à l’integration de la CLI glab comme CLI officielle de Gitlab, Certaines indications dans ce billet sont peut-être obsolètes!