Rajouter de la doc pour enlever le Pages Unique Domain sur les instances gitlab ?

[Ynote]

Je propose ce petit texte ci-dessous, je veux bien qu'on discute de où le mettre.

Activer son petit site sur gitlab.com ou git.scribouilli.org

1. Allez sur https://atelier.scribouilli.org.
2. Cliquez sur le lien "sur gitlab.com" ou "sur git.scribouilli.org" en haut à droite de l’écran.
3. Dans la barre latérale de gauche, cliquez sur "Deploy", un menu va s'ouvrir.
4. Dans ce menu, cliquez sur "Pages".
5. Sur la page, décochez la case "Use unique domain" et cliquez sur "Save changes"
6. Dans l'encart "Access pages", cliquez sur le lien de votre site pour vérifier qu'il est bien en ligne sur cette adresse. Ça peut parfois prendre plusieurs minutes pour se mettre à jour.

[maiwann]

Je ne comprends pas pourquoi il faut faire cette manip :x

[marienfressinaud]

J’ai ouvert un ticket de bug lié à cette manipulation (#167).

À noter aussi que si on a accédé à notre site sous la forme <nickname>.monpetitsite.org/<site> et été redirigé, le code de renvoi est une "308 Permanent Redirect" qui est gardé en cache par le navigateur. J’ai dû vider le cache en ouvrant les outils développeurs et en cliquant sur "Désactiver le cache" avant de charger l’URL.

@maiwann Gitlab coche cette case par défaut, ce qui a pour effet de générer des URLs de type <site>-<nickname>-<id aléatoire tout moche>.monpetitsite.org. Je crois que c’est lié au ticket #141 et que ça peut pas être désactivé automatiquement par Scribouilli malheureusement.

[DavidBruant]

Je vais raconter un peu de contexte sur ce qu'on a appris avec Fanny quand on a travaillé là-dessus, parce qu'on a pris des branches et des tapis un peu dans tous les sens
Et l'UX actuelle est le meilleur compromis qu'on a trouvé dans les temps imposé pour framalibre
Mais nous n'en sommes pas vraiment satisfaites, mais c'est un peu dur de faire mieux en l'état (de gitlab)

---

Sur Github, la vie est assez facile. Y'a Github pages avec son nom de domaine très stable par défaut. Et l'API github qui a le bon goût de nous transmettre l'URL de déploiement du github pages (même quand un nom de domaine custom a été installé).
Donc, on peut à la fois montrer la bonne adresse dans l'atelier Scribouilli et à la fois gérer le baseurl dans le _config.yml (qui permet que les URLs de CSS ne cassent pas en passant de yo.github.io/project à mon-site-perso-yo.org)

Sur Gitlab, ça se corse. Gitlab pages avait une convention similaire à Github Pages pour le domaine déployé (username.instance-gitlab.yo/project). Et puis récemment, ils ont décidé de mettre en place les Pages Unique Domain (pas de problème) et de les activer par défaut (waaaat!)
L'API Gitlab ne permet pas nous plus de récupérer l'URL de déploiement (et c'est VRAIMENT dommage quand y'a un morceau aléatoire qui traine dans le nom de domaine). Ou en tout cas, on n'a pas trouvé...

Alors on se retrouve à ne pas pouvoir mettre la bonne URL dans l'atelier (on utilise la convention passée parce qu'ils font un redirect, mais on ne sait pas combien de temps cette astuce va tenir). Et surtout, on a aucune manière de savoir via API si la base URL est / ou /project
Pour le contexte Scribouilli, on prend le partie de prioriser les utilisateur.rice.s qui ne vont jamais aller sur l'interface github/gitlab, et donc, on a hardcodé le baseurl à / (d'où le problème que tu as rencontré @marienfressinaud )

D'ailleurs, cette issue à propos d'expliquer aux personnes comment désactiver le Pages Unique Domain, on n'est même pas vraiment sûr.es que c'est une bonne idée

---

Voilà l'état des lieux de gitlab et de Scribouilli qui se débat avec l'état connu de gitlab

Avec Fanny, on s'est dit que la seule manière de correctement résoudre tout ça, ça serait de contribuer à Gitlab pour que l'API nous retourne l'URL de déploiement d'une manière ou d'une autre. Elle était motiv et suggérait que d'un point de vue code, c'est assez facile ; c'est plutôt passer le process de contribution de gitlab qui risque d'être laborieux