- Remplacer config.json par radar-business/config-business.json dans .techradar/data
- Copier explicitement team.html et team-visualization-data.json dans .techradar/public
- Les blips business sont copiés dans .techradar/data/radar/2025-01-15
- rm -rf .techradar/data/radar avant copie des blips business
- copie explicite de team.html et team-visualization-data.json dans .techradar/public
- logs inchangés
- Ajout d'un RUN pour compter les fichiers markdown copiés dans .techradar/data/radar
- Affiche aussi quelques noms pour vérifier que les blips sont bien copiés
- Script Python dans /tmp/add_team_link.py
- Plus lisible et fiable que Python inline
- Pas de problèmes d'échappement
- Gestion d'erreurs avec sys.exit
- Utilisation de sed en premier (plus simple)
- Fallback avec Python en une seule ligne si sed échoue
- Pas de heredoc complexe qui cause des problèmes d'échappement
- Création de team.tsx directement dans le Dockerfile
- Modification de Navigation.tsx avec Python inline
- Méthode alternative si le pattern regex ne fonctionne pas
- Plus simple et plus fiable que d'utiliser un script séparé
- Simplification de la gestion d'erreurs dans Dockerfile
- Suppression de set -e dans le script pour mieux gérer les erreurs
- Vérification que Navigation.tsx existe avant modification
- Affichage du contenu en cas d'échec
- Désactivation temporaire de set -e pour voir toutes les erreurs
- Capture du code de sortie du script
- Affichage du contenu de Navigation.tsx en cas d'échec
- Réactivation de set -e à la fin
- Utilisation de if/then au lieu de && pour mieux gérer les erreurs
- Affichage du contenu de Navigation.tsx en cas d'échec
- Affichage du contenu du dossier pages/ si team.tsx n'existe pas
- Messages d'erreur plus clairs
- Affichage du contenu de Navigation.tsx avant modification
- Affichage complet après modification pour vérification
- Exit code 1 si la modification échoue
- Logs détaillés pour identifier le problème
- Vérification explicite que team.html existe dans public/ source
- Logs détaillés pour identifier où le fichier se trouve
- Vérification après copie dans .techradar/public/
- Installation de Python3 dans Dockerfile
- Logs détaillés pour diagnostic
- Vérification après modification
- set -e pour arrêter en cas d'erreur
- Vérification dans Dockerfile que le script a réussi
- Script create-team-page.sh pour créer team.tsx et modifier Navigation
- Page Next.js qui charge team.html dynamiquement
- Lien Équipe ajouté directement dans le composant Navigation React
- Plus fiable que l'injection JavaScript
- Logs détaillés pour voir ce qui est copié dans out/
- Vérification du contenu de out/ avant et après copie
- Diagnostic amélioré pour identifier le problème
- Amélioration de la copie de team.html avec vérifications et logs
- Fonction initWhenReady() pour attendre que le header soit disponible
- Logs de debug pour vérifier l'ajout du lien Équipe
- Vérification de l'existence des fichiers avant copie dans out/
- Correction logique addLinksToHeader() pour éviter retour prématuré
- Utilisation d'un conteneur dédié pour les liens de navigation
- Copie explicite de team.html et team-visualization-data.json dans out/ après build
- Le lien Équipe s'affiche maintenant correctement dans le header
- Retrait de no_cache (non supporté dans docker-compose)
- Ajustement précis des positions pour les 4 quadrants (30px des bords)
- Les labels ne chevauchent plus les cercles du radar
- Amélioration de l'invalidation du cache dans Dockerfile
- Documentation pour utiliser 'No cache' dans Portainer
- Ajout d'un build arg CACHE_BUST avec timestamp pour invalider le cache
- Ajout d'une instruction RUN tôt dans le Dockerfile pour forcer l'invalidation
- Amélioration de la documentation avec guide détaillé pour forcer le rebuild
- Explication du problème de cache Docker et solutions multiples
- Instructions pour utiliser --no-cache dans Portainer
- Ajout de 'pull: true' dans docker-compose pour forcer le pull de l'image de base
- Ajout de build args (BUILD_DATE, BUILD_VERSION) pour invalider le cache
- Ajout de labels dans Dockerfile pour tracer les builds
- Cela évite d'avoir à supprimer manuellement l'image avant chaque rebuild
- Portainer utilisera maintenant toujours la dernière version du code
- Ajout de --include=dev pour installer tsx nécessaire à build:data
- Le script build:data utilise tsx qui est dans devDependencies
- Cela devrait résoudre l'erreur exit code 127 pour build:data
- Utilisation de WORKDIR pour changer de répertoire de manière fiable
- Cela évite les problèmes avec cd qui peuvent échouer silencieusement
- WORKDIR garantit que npm est disponible dans le bon contexte
- Retour à /app après le build
- Vérification que npm est disponible
- Vérification du répertoire de travail
- Séparation des commandes build:data et build pour identifier quelle étape échoue
- Cela devrait aider à identifier pourquoi exit code 127
- Copie de radar, public, config.json, about.md, custom.css dans .techradar
- Exécution de build:data avant build pour générer les données
- Cela reproduit ce que fait techradar.js automatiquement
- Le build devrait maintenant fonctionner correctement
- Ajout de vérifications pour voir si npm est disponible
- Affichage du package.json en cas d'échec pour déboguer
- Cela devrait aider à identifier pourquoi npm run build échoue
- Séparation de la commande de création du hash en une commande RUN distincte
- Utilisation de fs.writeFileSync au lieu de echo pour éviter les problèmes d'échappement
- Cela devrait résoudre l'erreur exit code 2
- Le script techradar.js ne prend pas 'install' comme paramètre
- Création manuelle de .techradar en copiant depuis node_modules/aoe_technology_radar
- Création du fichier hash pour éviter la recréation à chaque fois
- Cela évite les problèmes avec la commande 'install' qui n'existe pas
- Utilisation de 'node node_modules/aoe_technology_radar/bin/techradar.js install'
- Ajout d'une vérification pour voir si le binaire existe
- Cela évite les problèmes avec les permissions ou le chemin du binaire
- Remplacement de 'npx techradar install' par './node_modules/.bin/techradar install'
- Cela évite les problèmes avec npx qui peut ne pas trouver le binaire
- Le binaire est disponible après l'installation de aoe_technology_radar
- Séparation de la commande RUN complexe en plusieurs RUN distincts
- Cela permet d'identifier plus facilement quelle étape échoue
- Suppression du patch next.config.js qui n'est plus nécessaire en mode production
- Changement de NODE_ENV de development à production dans Dockerfile.business
- Build de l'application en mode production dans le Dockerfile
- Modification de start-business.sh pour utiliser 'next start' au lieu de 'next dev'
- Cela désactive complètement Fast Refresh et évite les rechargements en boucle
- Le mode production n'utilise pas Fast Refresh, donc pas de problème avec webpack hot-update
- Ajout d'un patch dans Dockerfile.business pour modifier next.config.js après installation
- Le patch supprime ReactRefreshPlugin de la configuration webpack en mode développement
- Cela devrait empêcher Fast Refresh de déclencher des rechargements en boucle
- Le problème venait du fait que le script strategie-script.js modifie le DOM, ce qui déclenche Fast Refresh
- Correction du Dockerfile.business pour préserver la structure radar/2025-01-15/ au lieu de copier directement dans radar/
- Cela permet au framework de parser correctement les dates et d'afficher les releases
- Ajout du script scripts/verify-blips.js pour vérifier le format des blips et des dates
- Tous les 36 fichiers blips vérifiés et validés (title, ring, quadrant, tags présents)
