8. Publier une page en ligne

Nous allons terminer la séance par la publication en ligne de pages en html que nous avons en local. Ainsi la forge peut servir de lieu d’hébergement pour publier soit des pages, soit des sites complets.

github, la forge de Microsoft permet de publier des pages à partir de fichiers écrits en markdown ou en html au moyen d’un générateur de site statique installé par défaut : Jeckyll. Cette fonction de github s’appelle github Actions.

Pour cette formation, on a décidé de se passer de Github et d’utiliser des forges gitlab avec un module équivalent qui permet d’afficher des pages web (Gitlab Pages).

Notons que quelque soit la forge, la publication de page n’est pas la seule action possible par rapport à un code source. Les forges sont reliées à des machines distantes, des runners, qui à partir d’un script écrit par l’utilisateur, va éxécuter le code source déposé pour obtenir la sortie souhaitée : ici, il s’agit de publier des pages web, dans d’autres projets, il sera plutôt question d’obtenir des données traitées en sortie ou de lancer une application. Ces actions comportent donc une dimension de test. Si ce processus d’intégration continue ne fonctionne pas, c’est que ou bien le script d’intégration continue est mal écrit, ou bien le runner n’est pas disponible, ou bien le code source présente un problème.

Revenons à la publication de nos pages

Ce processus consiste à :

créer une page d’accueil à partir d’un fichier qui aura comme nom ‘index’ (si on veut que le fichier recette.rmd apparaisse en entrant l’URL issue de la mise en ligne, renommer le ficher recettes.rmd en index.md)
rédiger des instructions de transformation des pages et de mise en ligne à chaque (instructions rédigées dans le fichier gitlab-ci.yml). Ces instructions qu’on appelle font partie du service d’ de la forge.
s’assurer que tous les internautes ont bien accès aux résultats de cette transformation, à savoir les pages web générées.

Rôle du fichier index :

si on ne crée pas de fichier index.md (ou index.html), l’URL généré ira vers une page vide (type erreur 404) On peut soit renommer son document maître (recette.md) en document index.md. Ou bien si on veut publier plusieurs pages et conserver une page d’atterrissage qui permettra de renvoyer vers les autres pages. Pour l’exercice, nous avons utilisé l’utilitaire Pandoc pour convertir les fichiers recette_far.md et recette_pizza.md dans leurs équivalents en pages web (recette_far.html et recette_pizza.html)

par exemple celle générée à partir de recette.md, on peut créer un fichier index.md et juste y ajouter le lien vers la page recette.md :

[lien vers la recette du far](recette_far.html)
[lien vers la recette du pizza](recette_pizza.html)

création d’un pipeline

cliquer dans le menu de gauche sur pipeline editor (où on va pouvoir ajouter le script mentionné plus haut)

Dans le champ à éditer, supprimer ce qui apparaît déjà et le remplacer par le script suivant :

pages:
  stage: deploy #il s'agit de déployer un site à partir de fichiers
  script:
  - mkdir .public # crée le dossier caché .public
  - cp -r Exercice/* .public/ # copie tous les dossiers et fichiers du dossier "Exervice dans le fichier caché .public
  - mv .public public # déplace tous les fichiers contenus dans le dossier caché public vers le dossier public
  artifacts: # indique où se trouve le résultat du script
    paths:
    - public/ 
  only:
  - main # indique que seule la branche *main* est concernée par ce workflow

écrire un message dans le formulaire, sous le code qu’on vient d’ajouter (là où il y a écrit “update .gitlab-ci.yml” qu’on peut remplacer par ce que l’on veut) de commit et committer. Si la syntaxe du texte entré est valide, un processus va se mettre en place qui va requérir l’intervention d’une machine virtuelle.

Cette machine virtuelle, dont on a parlé plus haut, le va tirer va exécuter toutes les actions qui sont énumérées dans ce script et notamment le déploiement des fichiers qu’on a stockés dans le dossier .public vers le dossier où gitlab puise les fichiers à déployer.

Pour accéder aux pages créées, toujours dans le menu de gauche, cliquer sur Deploy puis sur Page. On peut aussi cliquer sur le lien Gitlab Pages dans le frame de droite. si tout s’est bien passé on doit arriver à cette page, comportant l’URL qu’on cherche à obtenir :

S’il y a un fichier index.md dans le repository, le lien devrait mener à l’équivalent html de ce fichier. Sinon, l’URL de la page est vide ; à cette URL, ajouter le nom du fichier recette.html : vous devriez voir apparaître votre recette.

Les URL fournies par la forge gitlab-humanum sont peu engageantes : https://introduction-git-et-gitlab-c9f528.gitpages.huma-num.fr/

Avec Framagit, on peut choisir son nom de domaine

Il faut le louer (≈20€ par an) pour obtenir une URL plus simple et personnalisée. C’est une fonctionnalité qui n’est pas rendue possible par les admins de la forge gitlab.huma-num.

# 8. Publier une page en ligne Nous allons terminer la séance par la publication en ligne de pages en html que nous avons en local. Ainsi la forge peut servir de lieu d'hébergement pour publier soit des pages, soit des sites complets. github, la forge de Microsoft permet de publier des pages à partir de fichiers écrits en markdown ou en html au moyen d'un générateur de site statique installé par défaut : Jeckyll. Cette fonction de github s'appelle github Actions. Pour cette formation, on a décidé de se passer de Github et d'utiliser des forges gitlab avec un module équivalent qui permet d'afficher des pages web (Gitlab Pages). Notons que quelque soit la forge, la publication de page n'est pas la seule action possible par rapport à un code source. Les forges sont reliées à des machines distantes, des runners, qui à partir d'un script écrit par l'utilisateur, va éxécuter le code source déposé pour obtenir la sortie souhaitée : ici, il s'agit de publier des pages web, dans d'autres projets, il sera plutôt question d'obtenir des données traitées en sortie ou de lancer une application. Ces actions comportent donc une dimension de test. Si ce processus d'intégration continue ne fonctionne pas, c'est que ou bien le script d'intégration continue est mal écrit, ou bien le runner n'est pas disponible, ou bien le code source présente un problème. Revenons à la publication de nos pages Ce processus consiste à : 1. créer une page d'accueil à partir d'un fichier qui aura comme nom 'index' (si on veut que le fichier recette.rmd apparaisse en entrant l'URL issue de la mise en ligne, renommer le ficher *recettes.rmd* en *index.md*) 2. rédiger des instructions de transformation des pages et de mise en ligne à chaque {{< glossary push >}} (instructions rédigées dans le fichier *gitlab-ci.yml*). Ces instructions qu'on appelle {{< glossary pipeline >}} font partie du service d'{{< glossary "intcf5733e5-0370-4aae-8689-61bad1dd9ec0égration continue" >}} de la forge. 3. s'assurer que tous les internautes ont bien accès aux résultats de cette transformation, à savoir les pages web générées. ## Rôle du fichier index : si on ne crée pas de fichier *index.md* (ou index.html), l'URL généré ira vers une page vide (type erreur 404) On peut soit renommer son document maître (recette.md) en document *index.md*. Ou bien si on veut publier plusieurs pages et conserver une page d'atterrissage qui permettra de renvoyer vers les autres pages. Pour l'exercice, nous avons utilisé l'utilitaire Pandoc pour convertir les fichiers recette_far.md et recette_pizza.md dans leurs équivalents en pages web (recette_far.html et recette_pizza.html) par exemple celle générée à partir de recette.md, on peut créer un fichier index.md et juste y ajouter le lien vers la page recette.md : ```markdown [lien vers la recette du far](recette_far.html) [lien vers la recette du pizza](recette_pizza.html) ``` ## création d'un pipeline cliquer dans le menu de gauche sur *pipeline editor* (où on va pouvoir ajouter le script mentionné plus haut) ![](images/pipeline_editor.png) Dans le champ à éditer, supprimer ce qui apparaît déjà et le remplacer par le script suivant : ```{.yaml .code-overflow-wrap} pages: stage: deploy #il s'agit de déployer un site à partir de fichiers script: - mkdir .public # crée le dossier caché .public - cp -r Exercice/* .public/ # copie tous les dossiers et fichiers du dossier "Exervice dans le fichier caché .public - mv .public public # déplace tous les fichiers contenus dans le dossier caché public vers le dossier public artifacts: # indique où se trouve le résultat du script paths: - public/ only: - main # indique que seule la branche *main* est concernée par ce workflow ``` écrire un message dans le formulaire, sous le code qu'on vient d'ajouter (là où il y a écrit "update .gitlab-ci.yml" qu'on peut remplacer par ce que l'on veut) de commit et committer. Si la syntaxe du texte entré est valide, un processus va se mettre en place qui va requérir l'intervention d'une machine virtuelle. Cette machine virtuelle, dont on a parlé plus haut, le {{< glossary runner >}} va tirer va exécuter toutes les actions qui sont énumérées dans ce script et notamment le déploiement des fichiers qu'on a stockés dans le dossier .public vers le dossier où gitlab puise les fichiers à déployer. Pour accéder aux pages créées, toujours dans le menu de gauche, cliquer sur *Deploy* puis sur *Page*. On peut aussi cliquer sur le lien Gitlab Pages dans le frame de droite. si tout s'est bien passé on doit arriver à cette page, comportant l'URL qu'on cherche à obtenir : ![](images/deploy_page.png) S'il y a un fichier index.md dans le repository, le lien devrait mener à l'équivalent html de ce fichier. Sinon, l'URL de la page est vide ; à cette URL, ajouter le nom du fichier recette.html : vous devriez voir apparaître votre recette. Les URL fournies par la forge gitlab-humanum sont peu engageantes : *https://introduction-git-et-gitlab-c9f528.gitpages.huma-num.fr/* ::: {.callout-note} ## Avec Framagit, on peut choisir son nom de domaine Il faut le louer (≈20€ par an) pour obtenir une URL plus simple et personnalisée. C'est une fonctionnalité qui n'est pas rendue possible par les admins de la forge gitlab.huma-num. :::