Publier depuis Silex Desktop

Silex Desktop est un logiciel en alpha

La publication vers une forge git est récente. Si quelque chose ici ne correspond pas à ce que vous voyez, dites-le sur le forum ou dans une issue sur le dépôt de Silex.

Silex Desktop publie votre site en l'envoyant à une forge git. Votre site vit dans un dépôt qui vous appartient, la forge le construit, la forge le sert. Il n'y a pas de serveur Silex au milieu.

Trois forges sont gérées : GitLab, Forgejo (ce que fait tourner Codeberg) et SourceHut.

Ce qu'il vous faut d'abord

Silex lit ce que votre forge sait par la ligne de commande de cette forge : glab pour GitLab, tea pour Forgejo et Codeberg, hut pour SourceHut. Installez celle de votre forge et connectez-vous avec. Silex cherche ces programmes une seule fois, au premier lancement : installez-la donc avant d'ouvrir Silex Desktop pour la première fois. Sans elle, Silex dit qu'il ne sait pas comment publier ce site.

Silex envoie votre site avec le git de votre ordinateur. Il ne vous demande jamais de mot de passe ni de phrase de passe : git doit donc pouvoir pousser tout seul, avec une clé SSH que la forge connaît, ou un gestionnaire d'identifiants qui garde votre jeton.

Le dépôt sur la forge doit être vide. GitLab coche Initialize repository with a README quand vous en créez un, et un dépôt qui a déjà un commit a un historique qui n'a rien de commun avec votre site. Le push est alors refusé, et Silex n'a aucun moyen de s'en sortir.

Avant votre première publication sur Codeberg

Codeberg désactive les Actions sur chaque nouveau dépôt. Rien ne construit votre site tant que vous ne les activez pas, que le dépôt soit public ou privé.

Ouvrez votre dépôt sur Codeberg, allez dans Settings, puis l'onglet Units, et cochez Actions. Publiez à nouveau ensuite.

Codeberg ne sert par ailleurs les pages que depuis un dépôt public. Un dépôt privé peut construire votre site, mais personne ne pourra le voir, pas même vous.

Silex vous prévient quand aucun build n'a démarré, et vous met le lien vers la page où activer les Actions. Vous n'avez donc pas à retenir tout ceci, mais le savoir vous évite une attente.

Ce que Silex dépose dans votre dépôt

À la publication, Silex écrit cinq choses à côté de vos pages, puis les commite et les pousse :

Fichier	À qui il appartient
public/	À Silex. Vos pages publiées, vos styles et vos images.
build.json	À vous. Créé une fois avec une valeur par défaut, jamais réécrit.
build.sh	À Silex. Regénéré depuis build.json à chaque publication.
.gitignore	À vous. Silex y ajoute _site/ une fois et laisse le reste tranquille.
Le fichier de pipeline de votre forge	À Silex, jusqu'à ce que vous en décidiez autrement — voir plus bas.

Ce fichier de pipeline s'appelle .gitlab-ci.yml chez GitLab, .forgejo/workflows/pages.yml chez Forgejo et .build.yml chez SourceHut. _site/ est l'endroit où build.sh écrit le site construit, d'où le fait qu'il soit ignoré : il est refait à chaque build.

Reprendre la main sur le fichier de pipeline

Chaque fichier de pipeline écrit par Silex commence par cette ligne :

# silexOverwrite: true

Elle signifie ce fichier appartient à Silex, qui le réécrira à chaque publication. Supprimez cette ligne et le fichier est à vous — Silex n'y touchera plus jamais.

C'est ce qu'il faut faire pour changer quelque chose que Silex ne propose pas en réglage :

• le temps accordé au build (voir plus bas),
• la fréquence à laquelle elle tourne, pour un site alimenté par une source de données,
• des étapes supplémentaires qui vous sont propres.

C'est réversible : remettez la ligne et Silex reprend le fichier à la publication suivante.

Changer la taille de la machine de build

Codeberg prête ses machines gratuitement et demande que chaque job prenne la taille dont il a besoin, pas plus. Silex demande la plus petite, codeberg-tiny, et l'écrit dans le workflow :

jobs:
  pages:
    runs-on: codeberg-tiny
    timeout-minutes: 2

Le nom de la machine est un champ de la fenêtre de publication, Build machine name. Changez-le là pour demander une machine plus grosse, ou pour nommer les machines d'un Forgejo qui n'est pas Codeberg. Un nom auquel aucune machine de ce serveur ne répond veut dire que rien ne construira jamais votre site, et Silex vous le dit après une minute d'attente.

Label	Processeurs	Mémoire	Temps accordé
codeberg-tiny	1	2 Go	2 min
codeberg-small	2	4 Go	5 min
codeberg-medium	4	8 Go	10 min

Le chiffre de mémoire comprend ce que votre build écrit sur le disque, plus 2 Go d'espace temporaire.

Le temps accordé, lui, n'est pas un champ : Silex écrit toujours timeout-minutes: 2, qui est ce pour quoi codeberg-tiny est prêtée. Pour donner à une machine plus grosse le temps qui va avec, retirez la ligne silexOverwrite et montez timeout-minutes vous-même.

Republier sans ouvrir Silex

Utile quand votre site lit un CMS ou une source de données : le contenu a changé, le site non, et vous voulez une reconstruction sans ouvrir Silex du tout.

GitLab

À intervalle régulier — le plus simple pour un site alimenté par des données. Build → Pipeline schedules → New schedule, choisissez la fréquence, branche cible main. Votre site se reconstruit tout seul.

Depuis votre CMS, avec un jeton de déclenchement. Créez-le dans Settings → CI/CD → Pipeline trigger tokens, puis appelez-le depuis là où vit votre contenu :

curl --request POST \
  --form token=<votre jeton de déclenchement> \
  --form ref=main \
  "https://gitlab.com/api/v4/projects/<id du projet>/trigger/pipeline"

Avec un jeton d'accès personnel, si vous en avez déjà un :

curl --request POST \
  --header "PRIVATE-TOKEN: <votre jeton>" \
  "https://gitlab.com/api/v4/projects/<id du projet>/pipeline?ref=main"

L'identifiant du projet est sur sa page d'accueil, sous son nom.

À la main — Build → Pipelines → Run pipeline.

Forgejo et Codeberg

À la main — l'onglet Actions de votre dépôt, choisissez le workflow pages, puis Run workflow.

Depuis votre CMS, avec un jeton créé dans Paramètres → Applications :

curl --request POST \
  --header "Authorization: token <votre jeton>" \
  --header "Content-Type: application/json" \
  --data '{"ref":"main"}' \
  "https://codeberg.org/api/v1/repos/<propriétaire>/<dépôt>/actions/workflows/pages.yml/dispatches"

À intervalle régulier — Silex n'en configure pas, parce que cela reconstruirait votre site que quelque chose ait changé ou non. Pour en ajouter un, reprenez la main sur le fichier du workflow (retirez la ligne silexOverwrite) et ajoutez un schedule: à côté de workflow_dispatch: :

on:
  push:
    tags:
      - '_silex_*'
  workflow_dispatch:
  schedule:
    - cron: '0 4 * * *'

SourceHut

Le manifeste de build indique d'où cloner, il peut donc être envoyé seul :

hut builds submit .build.yml

Où votre site arrive

Quand le build se termine, Silex vous dit que votre site est en ligne et propose deux boutons, View your website et Address and domain. Ce que Silex sait de cette adresse dépend de la forge.

Codeberg et Forgejo. La fenêtre de publication demande trois choses avant d'envoyer : le domaine qui sert vos pages, codeberg.page chez Codeberg ; le nom de la machine de build, codeberg-tiny chez Codeberg ; et un domaine à vous, qui reste vide si vous n'en avez pas. Silex déduit l'adresse du domaine des pages, de votre nom de compte et du nom du dépôt : il la connaît donc dès la première publication. Un dépôt nommé pages est servi à la racine de votre sous-domaine, tout autre dépôt sous un chemin à son nom.

SourceHut. La fenêtre de publication demande l'adresse à laquelle pages.sr.ht sert votre site. Le champ est vide, parce qu'une mauvaise devinette publierait par-dessus un autre de vos sites. Laissez-le vide et le build publie quand même vers <votre compte>.srht.site, mais Silex dit qu'il ne connaît pas l'adresse.

GitLab. Il n'y a pas de champ. Silex demande l'adresse à GitLab avant d'envoyer votre site, et GitLab n'en a aucune tant qu'un build n'est pas terminé. La première publication se termine donc sur « Your website is built » et Silex qui dit ne pas connaître l'adresse. Publiez une deuxième fois et l'adresse est là. GitLab réserve aussi les Pages aux membres du dépôt tant que vous n'en décidez pas autrement, et Silex vous le dit quand c'est le cas.

Ce que vous répondez dans la fenêtre de publication est conservé avec votre site et proposé à nouveau la fois suivante.

Address and domain ouvre une page différente selon la forge : les réglages Pages de votre projet chez GitLab, les réglages où l'on active les Actions chez Codeberg et Forgejo, et pages.sr.ht chez SourceHut. Pointer un domaine à vous vers votre site se fait sur la forge, pas dans Silex. Chez Codeberg, cela passe par un fichier .domains dans votre dépôt.

Quand la publication échoue

Le dépôt contient des changements que Silex n'a pas. Quelqu'un a poussé depuis une autre machine. Silex ne fusionne rien pendant une publication : il s'arrête et vous dit de rouvrir le site depuis la liste des sites. L'ouvrir récupère ce qui peut l'être, et vous publiez à nouveau. Les changements qui contredisent les vôtres vous sont laissés, à vous et au client git que vous avez déjà.

Silex n'arrive pas à joindre la forge. Vous verrez ce que git a répondu. Silex ne demande jamais de mot de passe ni de phrase de passe : la cause habituelle est que git n'arrive pas à se connecter tout seul, avec une clé SSH que la forge ne connaît pas, ou un jeton expiré.

Codeberg n'a rien construit. Les Actions sont désactivées sur le dépôt. Voir le haut de cette page.

Il ne se passe rien après une publication. Seul un tag nommé _silex_… démarre un build. Si vous posez un tag sur votre dépôt pour vos propres raisons, cela ne publie pas votre site — c'est voulu.