Comment je publie mon blog statique depuis mon iPad

Après sept ans de bons et loyaux services, pendant lesquels nous avons parcouru quelques dizaines de milliers de kilomètres et écrit quelques centaines de milliers de mots ensemble, mon fidèle MacBook Pro 13" commence à montrer des signes de faiblesse. L’écran perd son revêtement mais garde la trace des icônes et des fenêtres, la batterie se décharge à toute vitesse mais le contrôleur oublie parfois de la recharger, les ports USB résistent encore mais le lecteur de cartes SD n’est pas loin de flancher.

Comme je peux difficilement justifier l’acquisition d’un nouveau MacBook Pro à plus de 2 000 €, j’ai largement anticipé mon passage à plein temps à l’iPad, et acheté un iPad Air 4 avec son Magic Keyboard. Cela ne change pas grand-chose : voilà onze ans que j’utilise un iPad ou un autre pour trier mes courriers, gérer les forums de MacGeneration, lire des articles et des livres, prendre des notes, éditer des papiers, dessiner des croquis et des maquettes, développer des photos, et même enregistrer des podcasts.

Mais cela change tout : j’ai toujours pu compter sur mon MacBook Pro pour effectuer les tâches demandant d’enchainer plusieurs actions ou d’utiliser la ligne de commande. Voire les tâches demandant d’enchainer plusieurs actions et d’utiliser la ligne de commande, comme la publication de Zinzolin. La rédaction est bien rodée – après tout, c’est mon métier. J’écris dans Ulysses, je corrige avec Antidote, et je dépose sur Github avec Working Copy.

La publication est plus compliquée – j’ai aussi abandonné mes serveurs dédiés pour des hébergements mutualisés. Sans accès SSH sur le serveur, je ne peux plus utiliser Prompt pour mettre à jour le dépôt Git et compiler le site à distance. Sans interface en ligne de commande sur l’iPad, je ne peux pas compiler le site en local et le transférer en FTP avec FileBrowser. La solution consiste, comme dans bien d’autres cas, à utiliser un serveur intermédiaire.

Plutôt que de redémarrer mon serveur domestique, j’ai profité de l’occasion pour tester l’intégration continue sur Github. Mon action de publication n’a rien de bien de sorcier : elle rafraichit les dépôts du site et du thème, installe la dernière version en date de Hugo, compile le site, et transfère les fichiers sur mon serveur. Les informations de connexion sont enregistrées sous la forme de « secrets » chiffrés.

name: publish

on:
  push:
    branches: main
  schedule:
    - cron:  '30 11 * * *'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v2
      
      - name: Checkout theme
        run: git submodule update --init --recursive
          
      - name: Setup Hugo
        uses: peaceiris/actions-hugo@v2
        with:
          hugo-version: 'latest'
          
      - name: Build site
        run: hugo --minify
        
      - name: Deploy site
        uses: SamKirkland/FTP-Deploy-Action@4.0.0
        with:
          protocol: ftps
          server: ${{ secrets.FTP_SERVER }}
          username: ${{ secrets.FTP_USERNAME }}
          password: ${{ secrets.FTP_PASSWORD }}
          server-dir: ${{ secrets.FTP_REMOTE_DIR }}
          local-dir: ./public/

Le switch vers l’iPad ne consiste pas simplement à dupliquer ses méthodes de travail, mais plutôt à les repenser, et tirer parti des limitations du système. Ainsi, cette action finit par simplifier la publication. Une fois que j’ai envoyé les fichiers avec Working Copy, l’action se déclenche automatiquement, et le site est mis à jour deux minutes plus tard, sans autre intervention de ma part. Et comme l’action se déclenche aussi tous les jours à 11 h 30, je peux prévoir la publication des photos plusieurs mois à l’avance. Reste… à écrire.