Open DavidBruant opened 8 months ago
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/
Ok, donc le plan, ça serait, dans l'ordre :
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)
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 :
site-scribouilli
(sur github et gitlab)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)
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...
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.
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)
Jusqu'à présent, ça a l'air ok… 🤔
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
Problème
Quand je vais sur les github actions d'un site déployé récemment avec Scribouilli, je vois :
Post de blog de Github : https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/
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éploiementsSolution
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