Dans le numéro de JavaScript Weekly de la semaine dernière, on trouve notamment Dynamic GitHub profile with Bun and Typescript où l'auteur explique comment il personnalise et surtout rend dynamique son profil GitHub. Cet article m'a rappelé que j'avais dans mes brouillons un billet sur le même sujet et comme j'utilise une approche un peu différente, c'est l'occasion de le terminer de parler un peu de la plomberie l'envers du décor.

La personnalisation d'un profil GitHub est simple à mettre en place, il suffit de créer un dépôt nommé comme votre nom d'utilisateur username/username et d'y ajouter un fichier README.md à la racine pour que son contenu soit repris sur le profil. Pour moi, le README.md de https://github.com/dpobel/dpobel se retrouve sur la page profile, ce qui donne quelque chose comme :

Il reste donc à mettre à jour régulièrement ce fichier pour que le profil affiche des informations à jour. Dans mon cas, en plus d'une courte introduction, je souhaite afficher les derniers billets publiés sur ce site ainsi que quelques billets sélectionnés. Comme l'auteur de l'article cité plus haut, je pourrais mettre un peu de code dans le dépôt username/username et lancer régulièrement un script via GitHub Actions (ou autre) pour mettre à jour le README.md à partir de flux RSS. Néanmoins, je vois au moins deux inconvénients dans cette approche (qui a quand même le mérite d'une certaine simplicité) :

1. il faut nécessairement ajouter du code dans le dépôt username/username ce qui implique un peu de maintenance
2. l'action de mise à jour doit être configurée pour s'exécuter régulièrement quelque soit l'activité sur ce site, compte tenu des hauts et des bas des publications par ici, ce n'est probablement pas une utilisation de ressources très efficace 😉

Par ailleurs, au moment où j'ai voulu mettre en place cette personnalisation, j'avais un besoin proche qui consistait à également tenir à jour https://dpobel.github.io/ en fonction de l'activité ici. Là encore, j'aurais pu mettre un peu de code dans le dépôt correspondant pour construire une page ce qui aurait occasionné les mêmes inconvénients.

Bref, en cherchant une alternative, j'ai découvert que GitHub expose une API REST qui permet notamment de déclencher un workflow GitHub Actions offrant ainsi une manière d'éliminer le second inconvénient. À partir de là, j'ai réalisé que je pouvais facilement ajouter dans la construction de ce site la génération du README.md pour le dépôt username/username et d'une page HTML destinée à https://dpobel.github.io/ et qu'ensuite à l'issue du déploiement, il suffisait de déclencher un workflow GitHub Actions par API pour chacun de ces dépôts qui peuvent se contenter de télécharger un fichier et de le commiter. De cette manière, l'essentiel de la logique est concentré dans la construction de ce site qui pilote les mises à jour externes.

Pour résumer la recette de ma potion magique 🧙 :

1. générer le README.md sur son site pour qu'il soit déployé avec le reste (ou le rendre disponible à une URL connue si vous utilisez un CMS dynamique)
2. Configurer un workflow GitHub Actions pour télécharger ce fichier et le commiter sur le dépôt username/username
3. sur un évènement par exemple au déploiement ou si vous utilisez un CMS sur la publication d'un nouveau contenu, faire un appel API pour déclencher ce workflow.

Et hop la magie opère ✨️ La même mécanique est à l'œuvre pour la mise à jour de https://dpobel.github.io/. Si j'en crois l'historique des commits du dépôt pour le profil et de celui de la page, la magie opère depuis un peu plus de 3 ans sans quasiment aucune intervention manuelle sur ces dépôts.