📜 Pages

Si vous n'avez pas fait les parties précédentes (issues et/ou CI)

Créer un nouveau projet simple aka "Blank project"

Gitlab propose la fonctionnalité Pages pour facilement exposer un site statique à partir de sources dans un repository.

🐥 Ma première Pages

• Dans le meme projet, via le WebIDE
  1. créer un répertoire public contenant un fichier index.html avec un petit bout de code HTML simple (snippet)
  2. modifier fichier .gitlab-ci.yml à la racine du projet
  3. ajouter un stage deploy et un job pages pour ce stage
     • ceux sont 2 mots clés protégés en Gitlab CI
     • faire du répertoire public un artifact du job
     • 🐒 vous pouvez vous inspirer du snippet
  4. commiter sur main
  5. aller voir le pipeline qui s'exécute

Tip

Le job n'a pas besoin des autres jobs, on peut préciser qu'il ne dépend d'aucun autre pour accélérer son exécution

Success

Le pipeline doit s'exécuter avec succès 🎉

NB: un job a été automatiquement ajouté pages:deploy, c'est celui-ci qui déploie le site statique

Une fois le pipeline exécuté correctement, aller dans le menu Deploy > Pages et trouver l'url de votre site

Success

Le site est déployé et accessible 👍

♻️ Mon premier environnement

Pour simplifier l'accès au site, on peut également le lier à un environnement

Dans le fichier .gitlab-ci.yml en passant soit par le WebIDE soit par le menu Build > Pipeline editor :

1. ajouter le paramétrage nécessaire dans le job pages pour qu'un environnement soit créé avec le nom de la branche
2. commiter
3. une fois le pipeline exécuté avec succès, aller dans le menu Operate > Environments

Success

Le site est déployé et accessible depuis le menu Environments avec le nom main

L'utilisation des environnements pour les pages reste limitée. Plus globalement, cela permet de déployer une application et la lier à un environnement et donc une version du code. Cela amène de la tracabilité sur quelle version a été déployée et quand.

NB: Ce n'est pas GitLab qui héberge l'application déployé. GitLab fait le lien entre un environnement (une URL) et la version du code source associée.

📦 Release du projet

On peut classiquement tagger notre branche main pour fixer une version. GitLab propose en complément la notion de Release permettant d'avoir un package comprenant cette version.

Depuis la version 15.7, une nouvelle CLI est disponbible : glab. Celle-ci permet d'intéragir facilement avec GitLab et entre autres de créer une release.

1. Dans le .gitlab-ci.yml, ajouter un job 📦_release-with-glab dans le stage release pour créer une release à partir d'un tag

   1. pour que glab fonctionne il faut d'abord s'authentifier en utilisant un access token que l'on peut générer depuis le menu Preferences > Access Token, accessible en cliquant sur son avatar en haut à droite. Il faut que le token ait les droits api & write_repository
   2. Une fois authentifié, on peut alors générer sa release

   Tip

   Bien conservé ce token, vous en aurez besoin plusieurs fois pendant le TP

2. Il est surement préférable que le job de release ne s'exécute que lorsque l'on est sur un pipeline lié à un tag...

   1. Ajouter une rules dans ce sens.

3. Utiliser le snippet partiel, il faut remplacer:

   • *** par votre token
   • ??? par la règle qui va bien pour que le job ne s'exécute que sur un pipeline lié à un tag
   • ### par la variable pré-définie pour récupérer le nom du tag

   Tip

   🔑 Mettre un token en dur dans le fichier .gitlab-ci.yml est une mauvaise pratique de sécurité. Mettre sa valeur dans une valeur de CI/CD

4. Commiter

5. Depuis le menu Code > Tags, créer un tag v1.0
6. Générer une release avec comme titre 🎉 Release <nom_tag>

Success

• La release apparait dans Deploy -> Releases avec le titre 🎉 Release ✅
• Le job de release ne s'exécute que sur les pipelines liés à un tag ✅
• Les pipelines de main & des tags s'exécutent correctement ✅