Les sites Scribouilli sur Github ne se déploieront plus après le 3 juin 2024

[DavidBruant]

Problème

Quand je vais sur les github actions d'un site déployé récemment avec Scribouilli, je vois :

build Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3, ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf, actions/configure-pages@v3, actions/upload-artifact@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

deploy Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/deploy-pages@v2. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Post de blog de Github : https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/

Our plan is to transition all actions to run on Node 20 by Spring 2024. We will actively monitor the migration's progress and gather community feedback before finalizing the transition date.

Bon, ça sent pas bon quand même

Un problème qu'on a nous, c'est que les personnes qui n'y connaissent rien ont leur propre repo et ne mettront pas à jour manuellement leur fichier .github/workflows/build-and-deploy.yml Et donc, à un moment, Github risque de refuser de faire tourner ces fichiers et donc empêcher les déploiements

Solution

Je tente une idée : on peut avoir le contenu du fichier .github/workflows/build-and-deploy.yml de référence quelque part (genre https://github.com/Scribouilli/site-template/blob/main/.github/workflows/build-and-deploy.yml ) et l'atelier vérifie régulièrement si le contenu actuel (qu'on a dans le repo git côté front-end normalement) est similaire. S'il est similaire, on fait rien, s'il est différent, on met à jour avec le fichier de référence

Ça pose direct la question des personnes qui ont leur propre fichier qu'on viendrait écraser par erreur. Et ça relance l'idée d'une option "je sais ce que je fais" évoquée précédemment

[DavidBruant]

Ce post de blog parle du 13 mai https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

[DavidBruant]

Ok, donc le plan, ça serait, dans l'ordre :

• [x] mettre à jour les actions actions/checkout, https://github.com/ruby/setup-ruby/commit/55283cc23133118229fd3f97f9336ee23a179fcf, actions/configure-pages, actions/upload-artifact et actions/deploy-pages dans https://github.com/Scribouilli/site-template/ pour que ça continue de marcher (puis https://github.com/Scribouilli/site-template-framalibre une fois que ça marche sur l'autre)
  • Une fois qu'on a ça, tous les nouveaux sites se déploieront correctement
• [ ] Coder une option pour les gens qui utilisent Scribouilli et savent ce qu'iels font et peuvent opt-out des mises à jour automatiques de fichiers workflow
  • [ ] parser/éditer le fichier config.yml avec un parser qui préserve les commentaires
• [ ] coder un truc qui vérifie que le fichier workflow dans le site scribouilli est bien égal à la version de référence. S'il n'est pas égal, alors remplacer le fichier workflow. Côté solution, on peut cloner le repo template et comme ça, c'est très facile/léger de faire un pull pour vérifier les maj. Ptèt faire la même avec d'autres fichiers (gemfile, ruby-version ?)
  • Une fois qu'on a ça, les anciens sites comme les nouveaux se mettront à jour automatiquement après le 13 mai

[DavidBruant]

https://github.com/Scribouilli/site-template/pull/4

[DavidBruant]

coder un truc qui vérifie que le fichier workflow dans le site scribouilli est bien égal à la version de référence

Et évidemment, c'est + dur qu'il n'y parait si on souhaite ne pas avoir d'interférences destructrices avec les repo non-scribouilli

dans le site scribouilli

Ça pourrait ressembler à ça :

Est-ce que le repo est un site Scribouilli ?
    => oui. Est-ce que la personne sait se débrouiller ?
      => oui => on ne fait rien
      => non => on update automatiquement
    => non => on ne fait rien

La question "Est-ce que le repo est un site Scribouilli ?" est un peu dure à répondre surtout pour des repos Scribouilli anciens Et donc, on va faire 2 choses :

1. inventer un signal explicite dans le repo pour dire qu'un site est un site Scribouilli (genre scribouilli: true dans le _config.yml)
2. Aller voir si le repo a des signaux explicites, même si plus ambiguës :

• utilisation du topic site-scribouilli (sur github et gitlab)
• présence du mot "Scribouilli" dans le fichier workflow
• présence du mot "Scribouilli" dans le fichier Licence En cas d'un de ces signaux faibles, rajouter le signal explicite non-ambiguë

la version de référence

à la base, je me disais qu'il faudrait garder une trace du repo template, mais c'est dur, au moins pour github parce que ce lien est perdu

Et en fait, actuellement, les 2 templates ont exactement le même fichier et il y a peu de chances dans l'avenir que ça change tellement que ça alors on peut en prendre un seul en référence pour le moment et ça sera très bien Le problème pourra se poser plus tard (avec une solution ptèt dépendante de la plateforme, ptèt avec une propriété dans _config.yml, ptèt via des reconnaissances de commit, ptèt via reconnaissance de contenu)

[DavidBruant]

Concernant les topics et le template d'origine, pour github, ça a l'air facile à chopper

https://docs.github.com/en/graphql/reference/objects#repository

Props templateRepository et repositoryTopics (l'utilisation d'un de nos template est un signal explicite ambiguë aussi)

Pour gitlab,

https://docs.gitlab.com/ee/api/projects.html

on récupère topics et (et sans simple), il y a une import_url, donc ptèt on peut s'en sortir comme ça...

[DavidBruant]

Soit, j'avais mal lu, soit Github a changé la date entre temps

Following on from our warning in workflows using Node16 we will start enforcing the use of Node20 rather than Node16 on the 3rd of June.

[DavidBruant]

De ce que je comprends, ptèt que les sites Scribouilli se mettront quand même à jour après cette date, mais c'est un peu la loterie (ça dépend de si les github actions qu'on utilise dans nos workflow sont compatibles avec Node.js 20)

[maiwann]

Jusqu'à présent, ça a l'air ok… 🤔

[DavidBruant]

Jusqu'à présent, ça a l'air ok… 🤔

Oui, on ne prend que des warnings et les github actions tournent quand même avec Node.js 20 apparemment https://github.com/DavidBruant/carnets-de-sefina/actions/runs/9537041949

J'imagine que ça veut dire qu'on est tranquille un moment et je priorise quand même ça parce que j'ai pas envie d'attendre la dépréciation suivante :-p

[elegaanz]

Une autre action GitHub qu'on a utilisé à une époque est dépréciée : https://github.com/Maiana8L/portfolio/actions/runs/13227933568/job/36921186364 Et ça casse tout, avec ce message :

Error: This request has been automatically failed because it uses a deprecated version of `actions/upload-artifact: v3`. Learn more: https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/