J’avais déjà parlé d’Amplify, qui est la technologie AWS qui fait tourner ce blog, entre autre. En fait, le blog est un site statique généré par Hugo. Amplify est le liant entre le web et le repository CodeCommit où le code Hugo est stocké, en plus d’être le composant servant et exposant le tout sur le net.

Rapidement et comme exposé sur la page dédiée, quand je commit un nouvel article ou une modification dans mon repository CodeCommit, cela déclenche un “build” Amplify, une génération exactement, elle-même configurée via un fichier YAML ressemblant à ceci:

version: 0.1
frontend:
  phases:
    build:
      commands:
        - hugo
  artifacts:
    baseDirectory: public
    files:
      - '**/*'
  cache:
    paths: []

Concrètement, il se passe quoi? Amplify pull une image Amazon Linux (image par défaut), dans laquelle il utilise le binaire hugo dans un conteneur docker pour générer le contenu, puis il expose le répertoire public résultant.

A noter qu’Amplify ne fait pas que de l’Hugo mais peut lancer plein de générations ou de serveurs comme :

  • yarn
  • jekill
  • amplify cli
  • bundler
  • vuepress

Tout ça, c’est très cool. Seulement, il existe plusieurs versions de chacun de ces outils. Et là, le problème, c’est que la version par défaut utilisée sur Amplify n’est pas forcément la version qu’on a en local pour tester son code avant de le commiter.

Et là, ta ta taaaaaan… Les changements majeurs et non rétrocompatibles! Notamment en Hugo 0.60. Je suis passé sous Archlinux récemment, et ma version d’Hugo en local est bien plus à jour maintenant.

Les plus de Hugo 0.60, pour le thème que j’utilise :

  • Une vraie coloration syntaxique pour les blocs de code
  • Les emojis sont maintenant interprétés

Le contre :

  • Le front (dispo, liens, etc) est totalement pété

Bon, après, mon thème est pas mal modifié aussi par mes soins, donc c’est peut-être un peu de ma faute aussi.

En tout cas, nous serons d’accord sur un point : l’idéal ce serait de pouvoir choisir dans Amplify la version du composant que l’on souhaite utiliser pour une application donnée. Et j’en viens donc au sujet de cet article : la personnalisation des builds Amplify !

Pour chaque application, Amplify propose pleins de paramètres. Notifications de builds, management de domaine personnels, variables d’environnement, rewrite rules… Et notamment des paramètres permettant de personnaliser le build, les “build settings”. Dans ces “build settings”, j’ai les paramètres suivants:

Il y a donc possibilité de les éditer et de les personnaliser, pour choisir l’image de base et la version du docker qui va être utiliser pour générer le contenu. Je peux soit partir sur une image tout autre que Amazon Linux pour la base :

Notons que le conteneur docker n’a même pas à être sur le hub, il peut être dans un repository à vous, dans ECR ou ailleurs.

Soit ajouter dans “live package updates” une version qui surchargera la version normalement utilisée par Amplify pour générer le contenu :

Ce qui est possible pour tous les composants que propose Amplify.

Il ne me reste plus qu’à intégrer mon blog proprement en Hugo 0.60 en local en utilisant ma préprod dans Amplify pour validation, et passer le tout en production.