Comment je mets à jour mon thème Hugo en production

Quand on démarre avec Hugo, tout paraît simple :
un thème, quelques articles, un hugo build, et le site est en ligne.

Mais très vite, une vraie question arrive en production :

Comment mettre à jour un thème Hugo sans risquer de casser son site ?

C’est un sujet étonnamment peu documenté.
Voici donc mon setup réel, utilisé en production, et surtout pourquoi je l’ai conçu comme ça.

Mettre à jour un thème Hugo en production est rarement documenté, surtout lorsqu’on utilise git submodules et une CI/CD auto-hébergée.

Pourquoi Hugo ne met pas à jour les thèmes automatiquement

#

Hugo ne touche jamais à git :

• pas de git pull
• pas de mise à jour silencieuse
• pas de dépendances flottantes

Ce n’est pas une limitation, mais un choix de conception sain.

Un thème Hugo est une dépendance critique :

• paramètres renommés ou supprimés
• shortcodes modifiés
• layouts cassés
• version minimale de Hugo augmentée

Une mise à jour automatique pourrait :

• casser le build
• ou pire, produire un site cassé sans erreur visible

Mon setup en production

#

Voici le contexte exact :

• Site statique avec Hugo
• Thème Blowfish
• Thème installé en git submodule
• Dépôt hébergé sur Gitea
• CI/CD avec Gitea Actions
• Déploiement via SCP

Objectif :

> Automatiser la mise à jour du thème, de façon versionnée et traçable, sans mise à jour implicite au moment du build.

Mettre à jour le thème Hugo manuellement

#

Avant toute automatisation, la mise à jour du thème repose sur une commande git très simple.

Dans le cas d’un thème installé en submodule, la mise à jour consiste simplement à exécuter :

git submodule update --remote --merge themes/blowfish

Cette commande fait trois choses :

• elle récupère la dernière version du thème depuis son dépôt distant (–remote)

• elle met à jour le submodule vers ce nouvel état

• elle conserve un historique git propre via un merge explicite (–merge)

Aucune magie ici : le thème est mis à jour comme n’importe quelle dépendance versionnée, et le changement n’est effectif qu’après un commit.

Et Hugo Modules dans tout ça ?

#

Hugo propose une alternative aux submodules : Hugo Modules, basé sur l’écosystème Go.

Cette approche permet de déclarer un thème comme une dépendance distante, téléchargée automatiquement au build et verrouillée via go.sum.

C’est une solution tout à fait valable, notamment pour des projets plus complexes ou mutualisés.

De mon côté, j’ai volontairement choisi les git submodules :

• la version du thème est visible directement dans git
• aucun outillage Go supplémentaire n’est nécessaire
• le comportement est entièrement explicite et prévisible

Pour un site personnel ou technique, ce compromis me paraît plus simple et plus lisible.

Le principe retenu

#

J’ai choisi une approche volontairement simple et robuste :

1. Mise à jour automatique du thème
2. Commit uniquement s’il y a un changement réel
3. Push sur main
4. Déclenchement du workflow de build et de déploiement
5. Version du thème visible en production

Workflow de mise à jour du thème

#

Voici le workflow Gitea Actions que j’utilise en production pour mettre à jour automatiquement le thème Blowfish chaque lundi à 6 h, avec un commit explicite uniquement lorsqu’un changement est détecté.

name: Update Blowfish

on:
  schedule:
    - cron: "0 6 * * 1"
  workflow_dispatch:

jobs:
  update-blowfish:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          submodules: recursive
          fetch-depth: 0

      - name: Configure git
        run: |
          git config user.name "blowfish-bot"
          git config user.email "blowfish-bot@localhost"

      - name: Update Blowfish + version file
        run: |
          set -e
          git submodule update --remote --merge themes/blowfish

          BLOWFISH_VERSION=$(cd themes/blowfish && git describe --tags --always)
          echo "$BLOWFISH_VERSION" > static/blowfish-version.txt

          git add themes/blowfish static/blowfish-version.txt
          if git diff --cached --quiet; then
            echo "No changes to commit."
            exit 0
          fi

          git commit -m "chore(theme): bump Blowfish to $BLOWFISH_VERSION"

      - name: Push
        run: git push

Rendre la version du thème visible en production

#

À chaque mise à jour, le workflow écrit un fichier :

static/blowfish-version.txt

Ce fichier est servi tel quel par Hugo et accessible publiquement :

https://cryptolab.re/blowfish-version.txt

Exemple de contenu :

v2.97.0

Avantages :

• savoir exactement quelle version tourne en prod
• debug facilité
• rollback immédiat via git revert

Pourquoi ce setup est volontairement conservateur

#

Ce workflow :

• n’update jamais le thème pendant un build
• ne fait aucune magie cachée
• laisse un historique git propre
• permet un rollback instantané

Un thème n’est pas un détail cosmétique :
c’est une dépendance logicielle à part entière.

Ce que je ferais différemment pour un site critique

#

Pour un site à fort trafic ou critique, j’irais plus loin :

• mise à jour sur branche dédiée
• Pull Request obligatoire
• build Hugo bloquant avant merge
• version du thème figée sur des tags uniquement

Mais pour un site personnel ou technique, ce compromis est simple, lisible et fiable.

Conclusion

#

Hugo est simple.
La production ne l’est pas.

Traiter un thème comme une dépendance versionnée change tout :

• moins de surprises
• plus de contrôle
• déploiements sereins

C’est un petit effort d’ingénierie, pour un énorme gain de tranquillité.