Les Gitlab Pages débarquent dans Framagit !

Classé dans : Migration, Services en ligne | 8

Temps de lecture 6 min

image_pdfimage_print

La création d’un site web depuis votre compte Framagit est beaucoup plus souple, et c’est une belle victoire pour le libre !

Attention : ce billet comporte des éléments techniques… Si vous avez un compte Framagit et/ou si vous vous intéressez à la création d’un site web statique depuis un dépôt Git, il est fait pour vous ! Si vous n’avez pas tout compris à cette phrase, la suite va vous paraître délicieusement absurde :p !
NB : l’édition communautaire de Gitlab est la version libre de la forge logicielle Gitlab, qui existe aussi en version non-libre, appelée version entreprise. Bien évidemment, nous utilisons la version libre pour fournir le service Framagit 🙂
NB : les adresses IP pour utiliser votre propre domaine ont changé. Il faut maintenant faire pointer votre domaine vers les adresses 2a01:4f8:231:4c99 ::42 et 176.9.183.74 (ou faire un enregistrement CNAME vers frama.io).

Qu’est‐ce que GitLab Pages ?

À l’instar des pages Github, les pages GitLab permettent à toute personne possédant un dépôt sur une instance de GitLab de créer un site Web via un générateur de site statique (Jekyll, Middleman, Hexo, Hugo, Pelican…) et de l’héberger sur l’infrastructure dudit GitLab.

La compilation du site est effectuée lors du push vers le dépôt GitLab, via le système d’intégration continue de GitLab, puis le résultat est publié à l’endroit idoine pour être accessible via le Web. Il est possible d’utiliser un nom de domaine personnel (il n’est pas obligatoire d’utiliser une adresse du style https://username.gitlab.io), ainsi qu’un certificat personnel.

Et ça sert ?

Oui !

Les pages GitHub sont très souvent utilisées par les développeurs pour fournir une page de présentation de leurs projets, même les plus gros : Ruby on Rails, Django, React…

Les pages GitLab sont donc susceptibles d’être tout autant utilisées que les pages GitHub. La demande est là.

Mais on avait pas déjà un truc comme ça ?

Tout à fait ! J’avais créé Fs Pages pour fournir un service similaire mais plus limité que les Gitlab Pages car Gitlab ne souhaitait pas les intégrer à leur édition communautaire.

Il était possible de publier un site statique via Fs Pages mais la génération du site devait se faire avant de pousser le code : point de génération automatique. De plus, il n’était pas possible d’utiliser un nom de domaine personnel. Votre site statique répondait uniquement via l’adresse https://votre_utilisateur.frama.io.

Le long chemin de la libération

Nous n’allons pas refaire l’historique complet de la libération des Gitlab Pages, surtout que celui-ci est disponible sur LinuxFr. Mais un petit résumé succinct ne fera pas de mal.

Tout a commencé par un tweet de votre serviteur demandant à Gitlab s’il était envisageable d’avoir les Gitlab Pages dans l’édition communautaire de Gitlab (pas la peine de chercher les tweets en question, j’ai fermé mon compte twitter). Gitlab a ouvert un ticket pour discuter de cela.

Gitlab a exposé au fil du temps trois arguments :

  • seules les fonctionnalités utiles aux instances de moins de 100 utilisateurs peuvent aller dans l’édition communautaire (et pour eux, cela n’était pas le cas de Gitlab Pages)
  • https://gitlab.com, qui utilise la version entreprise — donc avec les Gitlab Pages — est libre d’utilisation pour tout un chacun, et contrairement à Github, les dépôts privés sont gratuits
  • les Gitlab Pages sont une fonctionnalité qui ajoute une réelle plus-value à l’édition entreprise : comment vendre leur produit si une des fonctionnalités majeures est déjà dans l’édition communautaire ?

Il est à noter que Gitlab nous a proposé d’utiliser la version entreprise avec un rabais, ce qui est tout à leur honneur, mais comme nous ne souhaitons utiliser que du logiciel libre, nous avons décliné (évidemment 😀)

La communauté a fait valoir que Gitlab Pages n’intéressait pas que les grandes instances, qu’utiliser https://gitlab.com ou Github revenait au même puisque cela équivaut à utiliser du logiciel propriétaire, proposa un financement participatif pour financer la libération et enfin avança que les Gitlab Pages feraient une bonne publicité à Gitlab, les développeurs utilisant de plus en plus fréquemment ce genre de solution pour héberger leurs sites ou leurs blogs. Et même si j’ai horreur de cet argument de notoriété, force m’est d’avouer qu’il a su faire mouche (ainsi que les plus de 100 « 👍 » du ticket) : la libération fut annoncée peu de temps après celui-ci !

En tout, la discussion a duré près de onze mois. Les échanges furent cordiaux et la communauté, opiniâtre, a su faire valoir ses arguments.

Bref, une bien belle victoire pour le libre qui voit là un logiciel apprécié se doter d’une nouvelle fonctionnalité très attendue !

Bon, et maintenant ?

Depuis la mise à jour de Framagit du 2 mars dernier, toute personne possédant un dépôt sur Framagit peut, via les Gitlab Pages, créer et héberger un site sur notre infrastructure, que ce soit en sous-domaine de frama.io (comme moi 😊) ou avec un domaine privé (auquel cas il faudra faire pointer un enregistrement DNS vers les IPs de frama.io : 144.76.206.44 et 2a01:4f8:200:1302 ::44 ou créer un enregistrement DNS de type CNAME vers frama.io.), avec ou sans certificat.

La documentation de Gitlab sur l’utilisation des Gitlab Pages (en anglais) est très complète et propose même un grand nombre de modèles sur lesquels vous baser. D’Hugo à Pelican en passant par des pages statiques développées à la main, il y en a pour tous les goûts !

Il n’y a que deux ombres au tableau :

  • l’utilisation de certificats Let’s Encrypt n’est pas aisée mais un ticket est ouvert chez Gitlab pour intégrer directement Let’s Encrypt aux Gitlab Pages
  • il n’y a pas de redirection automatique vers la version sécurisée (https) de votre site, quand bien même vous fourniriez un certificat ou que vous utilisiez un sous-domaine de frama.io (ce qui vous fournit automatiquement une version https de votre site grâce à notre achat d’un certificat wildcard (certificat valant pour le domaine et tous ses sous-domaines)). Un ticket est cependant ouvert chez Gitlab à ce sujet. En attendant, pour rediriger vos visiteurs vers la version https de votre site, vous pouvez néanmoins inclure ce petit bout de JavaScript dans vos pages :
    <script>
    var loc = window.location.href+'' ;
    if (loc.indexOf('http://')==0){
        window.location.href = loc.replace('http://','https://') ;
    }
    </script>

Le framablog n’étant pas un blog technique, nous ne étendrons pas plus sur les ficelles de Gitlab Pages : on va laisser ça pour notre site dédié à la documentation de nos services.

Au 20 mars, nous sommes déjà 31 (oui, bon, ok, sur 7 560 utilisateurs, ça fait peu) à avoir commencé à bidouiller sur les Gitlab Pages de Framagit (contre 53 quand nous proposions FsPages). Continuez comme ça ! 🙂

Crédits image :

Suivre Framasky:

adminSys

Debianeux convaincu, Perliste fou, administrateur système de métier, je passe mon temps à mettre les machines de Framasoft à jour ou à coder.

8 Responses

  1. Brice

    Ah mon dieu, c’est aussi récent que ça? J’avais pas suivi la chronologie, mais je m’en suis servi hier pour la première fois, et ça fonctionne du tonnerre!

    Bravo à vous pour cette bataille 🙂

  2. pvincent

    ça a l’air sympa, je vais jeter un oeil.
    merci @framasoft

  3. libre fan

    Bravo et mille mercis! (et bravo d’avoir largué Twitter, luc)

    Et merci pour cette page instructive et tous les liens.

  4. John Doe

    Super! 🙂

    Par contre, ce qui serait sympa c’est de ne pas forcer la redirection HTTPS, car si par exemple on utilise un autre domaine sans certificat … ben c’est cuit 😀

    • Framasky

      Je ne comprends pas votre demande… C’est à vous d’ajouter du code pour que votre site frama.io soit redirigé en HTTPS. Donc du coup, nous, on ne force rien.

      • John Doe

        Je me suis peut-être mal exprimé, désolé!

        Par exemple, je possède le domaine « mondomaine.fr » que je fait pointer vers une page « userframa.frama.io » ( par exemple avec un enregistrement DNS de type CNAME ).

        « mondomaine.fr » me redirigera automatiquement vers « http S ://mondomaine.fr » avec un certificat de type « *.frama.io », qui ne fonctionnera évidemment pas 😉

        C’était ça le petit soucis 😉