Publier depuis Silex Desktop

Brouillon — écrit le 21 août 2026, pas encore relu

Silex Desktop est un logiciel en alpha, et cette page a été écrite en même temps que la fonctionnalité qu'elle décrit. Elle n'a pas été relue. Certaines parties sont signalées plus bas comme non testées. Dites-nous ce qui est faux : le forum ou 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.

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 quatre 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.
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.

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 :

• la taille de la machine qui construit votre site (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 :

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

Y construire un petit site a pris 45 secondes, téléchargement de l'outil de build compris. Si votre site grossit et que le build manque de temps, retirez la ligne silexOverwrite et montez d'un cran :

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

Montez timeout-minutes en conséquence. Le chiffre de mémoire comprend ce que votre build écrit sur le disque, plus 2 Go d'espace temporaire.

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

Testé

Les deux commandes ci-dessus pour GitLab et Forgejo ont été exécutées sur de vrais dépôts en écrivant cette page, et toutes les deux ont démarré un build. Celle de SourceHut non — voir plus bas.

Où votre site arrive

Silex vous montre l'adresse dès que la forge en a une à donner. À la première publication il n'y a rien à montrer : le build n'est pas terminé, donc l'adresse n'existe pas encore.

Sur Codeberg et SourceHut, Silex vous demande l'adresse avant de publier : un champ apparaît dans la fenêtre de publication, prérempli avec l'adresse que la forge utilise d'habitude. Changez-la si vous avez un nom de domaine à vous. Ce que vous écrivez est conservé avec votre site et réutilisé la fois suivante.

Sur GitLab il n'y a pas de champ, parce que glab donne l'adresse tout seul.

La configuration du domaine lui-même — les enregistrements DNS, le certificat — se fait sur la forge, pas dans Silex. Silex vous met le lien vers la bonne page après chaque publication.

Quand la publication échoue

Le dépôt contient des changements que Silex n'a pas. Quelqu'un a poussé depuis une autre machine, ou la forge a ajouté un fichier à la création du dépôt. Silex se met à jour tout seul et publie. Si les changements contredisent les vôtres, il s'arrête et le dit, plutôt que d'écraser quoi que ce soit.

Silex n'arrive pas à joindre la forge. Vous verrez ce que git a répondu. La cause habituelle est que la machine n'a pas accès au dépôt — 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.