home.md

@@ -32,7 +32,7 @@ Avoir un environnement de staging depuis le repo et sans avoir besoin d'avoir un
 
 - Test du code (auto) ;
 - Test de l'application qui build (auto) ;
-- Rapport Lighthouse de performance, pour chaque Review App (auto) ;
+- ~~Rapport Lighthouse de performance, pour chaque Review App (auto)~~ désactivé, car la CI partagée n'est pas assez puissante ;
 - Test que l'application a bien été déployée (manuel, GitLab prend son temps pour vraiment publier, donc pas possible de le lancer en auto).
 
 ### C) De multiples environnements (Production, Staging et Reviews App)
@@ -64,35 +64,21 @@ Les Environnements temporaires utilisent des urls de `surge.sh`. Lorsque GitLab
 
 ## 4. Annexes
 
-## 4. Annexes
-
-### **TODO / Reste à faire / Autres idées**
-
 ### **TODO / Reste à faire / Autres idées**
 
 - Créer des index temporaires dans meilisearch pour chaque Env (staging et Review App) ;
 - Mettre en place un test d'impact écologique du site ;
 - Forcer l'utilisation d'un bon format de message de commit avec `husky` ;
 - Mettre en place un gestionnaire de version/historique.
-- Créer des index temporaires dans meilisearch pour chaque Env (staging et Review App) ;
-- Mettre en place un test d'impact écologique du site ;
-- Forcer l'utilisation d'un bon format de message de commit avec `husky` ;
-- Mettre en place un gestionnaire de version/historique.
-
-### Surge.sh
 
 ### Surge.sh
 
-Ajouter en Envar de CI `SURGE_LOGIN` et `SURGE_TOKEN`.
 Ajouter en Envar de CI `SURGE_LOGIN` et `SURGE_TOKEN`.
 
-Pour avoir son Token
 Pour avoir son Token
 
 ````sh
 cat ~/.netrc | grep -A2 surge.sh
-```sh
-cat ~/.netrc | grep -A2 surge.sh
 ````
 
 ---