Scribouilli / scribouilli

https://atelier.scribouilli.org/
MIT License
73 stars 14 forks source link

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

Open DavidBruant opened 8 months ago

DavidBruant commented 8 months ago

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 commented 6 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/

DavidBruant commented 6 months ago

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

DavidBruant commented 6 months ago

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

DavidBruant commented 6 months ago

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 :

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 commented 6 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

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

DavidBruant commented 3 months ago

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