ci: correction syntaxe Woodpecker (.woodpecker.yml)
- Suppression des headers Drone CI (kind/type/name) - Déplacement du trigger when: au niveau global - Volumes inline (host:container) au lieu des named volumes - Suppression de la section volumes: Drone en bas de fichier - Correction $$ → $ pour les variables dans les commandes - Chaînage des cd avec && pour les commandes radar-app - Image docker:27-cli cohérente avec le modèle de référence Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
syoul
234
.woodpecker.yml
234
.woodpecker.yml
@@ -1,207 +1,66 @@
|
|||||||
---
|
when:
|
||||||
kind: pipeline
|
- branch:
|
||||||
type: docker
|
- main
|
||||||
name: build-and-deploy
|
- stand-alone
|
||||||
|
event: push
|
||||||
# Ce pipeline Woodpecker CI automatise le build et le déploiement de l'application statique
|
|
||||||
# Il se déclenche automatiquement sur chaque push vers les branches main ou stand-alone
|
|
||||||
|
|
||||||
steps:
|
steps:
|
||||||
# ============================================
|
|
||||||
# ÉTAPE 1: BUILD DE L'APPLICATION STATIQUE
|
# Etape 1 : Build de l'application statique
|
||||||
# ============================================
|
|
||||||
# Cette étape construit l'application Next.js et génère les fichiers statiques HTML/CSS/JS
|
|
||||||
- name: build
|
- name: build
|
||||||
# Image Docker utilisée : Node.js 20 sur Alpine Linux (légère et rapide)
|
|
||||||
image: node:20-alpine
|
image: node:20-alpine
|
||||||
|
|
||||||
# Variables d'environnement nécessaires pour le build
|
|
||||||
environment:
|
environment:
|
||||||
NODE_ENV: production # Mode production (optimisations activées)
|
NODE_ENV: production
|
||||||
HUSKY: 0 # Désactive Husky (git hooks) pour éviter les erreurs
|
HUSKY: 0
|
||||||
HUSKY_SKIP_INSTALL: 1 # Skip l'installation de Husky
|
HUSKY_SKIP_INSTALL: 1
|
||||||
|
|
||||||
# Commandes exécutées dans l'ordre
|
|
||||||
commands:
|
commands:
|
||||||
# Installation des dépendances système nécessaires
|
|
||||||
# - git : pour cloner/récupérer des dépendances si nécessaire
|
|
||||||
# - python3 : requis pour les scripts de patch (patch_document.py, add_team_link.py)
|
|
||||||
- apk add --no-cache git python3
|
- apk add --no-cache git python3
|
||||||
|
|
||||||
# Installation des dépendances Node.js de la racine du projet
|
|
||||||
# npm ci : Clean Install (supprime node_modules et réinstalle depuis package-lock.json)
|
|
||||||
# --legacy-peer-deps : Ignore les conflits de dépendances peer (compatibilité)
|
|
||||||
- npm ci --legacy-peer-deps
|
- npm ci --legacy-peer-deps
|
||||||
|
- cd radar-app && npm ci --legacy-peer-deps --include=dev && npm run build:icons && cd ..
|
||||||
# Installation des dépendances de radar-app/ (le framework Next.js vendu)
|
|
||||||
# On se déplace dans le dossier radar-app pour installer ses dépendances
|
|
||||||
- cd radar-app
|
|
||||||
|
|
||||||
# Installation des dépendances de radar-app (y compris devDependencies)
|
|
||||||
# --include=dev : Inclut les dépendances de développement (tsx, eslint, etc.)
|
|
||||||
- npm ci --legacy-peer-deps --include=dev
|
|
||||||
|
|
||||||
# Build des icônes SVG en composants React TypeScript
|
|
||||||
# Ce script génère les composants Icons depuis les fichiers SVG dans src/icons/
|
|
||||||
- npm run build:icons
|
|
||||||
|
|
||||||
# Retour à la racine du projet
|
|
||||||
- cd ..
|
|
||||||
|
|
||||||
# Génération des données de visualisation équipe
|
|
||||||
# Ce script lit les profils dans docs/data/team/*.md et les technologies
|
|
||||||
# Il génère public/team-visualization-data.json utilisé par la page /team
|
|
||||||
- node scripts/generate-team-visualization-data.js
|
- node scripts/generate-team-visualization-data.js
|
||||||
|
|
||||||
# Build de l'application complète
|
|
||||||
# Ce script (build-radar.js) :
|
|
||||||
# 1. Copie config-business.json vers radar-app/data/config.json
|
|
||||||
# 2. Copie radar-business/2025-01-15/ vers radar-app/data/radar/2025-01-15/
|
|
||||||
# 3. Copie public/* vers radar-app/public/
|
|
||||||
# 4. Applique les patches (team page, _document, Navigation)
|
|
||||||
# 5. Lance npm run build:data puis npm run build dans radar-app/
|
|
||||||
# 6. Copie radar-app/out/ vers build/ à la racine
|
|
||||||
- npm run build
|
- npm run build
|
||||||
|
|
||||||
# Vérification que le build a réussi
|
|
||||||
# Affiche les 10 premiers fichiers du dossier build/ pour vérifier la génération
|
|
||||||
- ls -la build/ | head -10
|
- ls -la build/ | head -10
|
||||||
|
|
||||||
# Volumes temporaires pour accélérer les builds suivants
|
# Etape 2a : Deploiement via rsync (optionnel — choisir rsync OU docker, pas les deux)
|
||||||
# Ces volumes persistent les node_modules entre les étapes pour éviter de réinstaller
|
|
||||||
volumes:
|
|
||||||
- name: node_modules_root
|
|
||||||
path: /app/node_modules
|
|
||||||
- name: node_modules_radar_app
|
|
||||||
path: /app/radar-app/node_modules
|
|
||||||
|
|
||||||
# ============================================
|
|
||||||
# ÉTAPE 2: DÉPLOIEMENT VIA RSYNC (OPTIONNEL)
|
|
||||||
# ============================================
|
|
||||||
# Cette étape synchronise les fichiers statiques vers un serveur web distant
|
|
||||||
# Utile si vous avez un serveur Nginx/Apache qui sert des fichiers statiques
|
|
||||||
- name: deploy-rsync
|
- name: deploy-rsync
|
||||||
# Image Alpine (légère) avec rsync et SSH
|
|
||||||
image: alpine:latest
|
image: alpine:latest
|
||||||
|
|
||||||
# Variables d'environnement récupérées depuis les secrets Woodpecker
|
|
||||||
environment:
|
environment:
|
||||||
DEPLOY_HOST:
|
DEPLOY_HOST:
|
||||||
from_secret: deploy_host # Exemple: techradar.example.com
|
from_secret: deploy_host
|
||||||
DEPLOY_USER:
|
DEPLOY_USER:
|
||||||
from_secret: deploy_user # Exemple: deploy
|
from_secret: deploy_user
|
||||||
DEPLOY_PATH:
|
DEPLOY_PATH:
|
||||||
from_secret: deploy_path # Exemple: /var/www/techradar
|
from_secret: deploy_path
|
||||||
DEPLOY_KEY:
|
DEPLOY_KEY:
|
||||||
from_secret: deploy_key # Clé privée SSH complète
|
from_secret: deploy_key
|
||||||
|
|
||||||
commands:
|
commands:
|
||||||
# Installation des outils nécessaires
|
|
||||||
- apk add --no-cache openssh-client rsync
|
- apk add --no-cache openssh-client rsync
|
||||||
|
|
||||||
# Création du dossier .ssh pour les clés SSH
|
|
||||||
- mkdir -p ~/.ssh
|
- mkdir -p ~/.ssh
|
||||||
|
- echo "$DEPLOY_KEY" > ~/.ssh/id_rsa
|
||||||
# Écriture de la clé privée SSH dans le fichier id_rsa
|
|
||||||
# $$ est échappé pour éviter l'interpolation par le shell
|
|
||||||
- echo "$$DEPLOY_KEY" > ~/.ssh/id_rsa
|
|
||||||
|
|
||||||
# Protection de la clé privée (lecture/écriture uniquement pour le propriétaire)
|
|
||||||
- chmod 600 ~/.ssh/id_rsa
|
- chmod 600 ~/.ssh/id_rsa
|
||||||
|
- ssh-keyscan -H $DEPLOY_HOST >> ~/.ssh/known_hosts || true
|
||||||
|
- rsync -avz --delete build/ $DEPLOY_USER@$DEPLOY_HOST:$DEPLOY_PATH/
|
||||||
|
- echo "Deploiement termine sur $DEPLOY_HOST:$DEPLOY_PATH"
|
||||||
|
|
||||||
# Ajout de la clé publique du serveur dans known_hosts
|
# Etape 2b : Deploiement via Docker Compose (recommande)
|
||||||
# Évite la vérification manuelle lors de la première connexion
|
|
||||||
- ssh-keyscan -H $$DEPLOY_HOST >> ~/.ssh/known_hosts || true
|
|
||||||
|
|
||||||
# Synchronisation des fichiers
|
|
||||||
# rsync -avz : Archive mode, Verbose, Compression
|
|
||||||
# --delete : Supprime les fichiers sur le serveur qui n'existent plus localement
|
|
||||||
# build/ : Source (dossier build généré à l'étape précédente)
|
|
||||||
# $$DEPLOY_USER@$$DEPLOY_HOST:$$DEPLOY_PATH/ : Destination (serveur distant)
|
|
||||||
- rsync -avz --delete build/ $$DEPLOY_USER@$$DEPLOY_HOST:$$DEPLOY_PATH/
|
|
||||||
|
|
||||||
# Message de confirmation
|
|
||||||
- echo "✅ Déploiement terminé sur $$DEPLOY_HOST:$$DEPLOY_PATH"
|
|
||||||
|
|
||||||
# Conditions de déclenchement
|
|
||||||
# Cette étape ne s'exécute que si :
|
|
||||||
when:
|
|
||||||
branch:
|
|
||||||
- main # Sur la branche main
|
|
||||||
- stand-alone # Ou sur la branche stand-alone
|
|
||||||
event:
|
|
||||||
- push # Et uniquement sur un événement push (pas sur les PR)
|
|
||||||
|
|
||||||
# ============================================
|
|
||||||
# ÉTAPE 3: DÉPLOIEMENT DOCKER (RECOMMANDÉ)
|
|
||||||
# ============================================
|
|
||||||
# Cette étape build et déploie l'application via Docker
|
|
||||||
# Plus simple et reproductible que rsync
|
|
||||||
- name: deploy-docker
|
- name: deploy-docker
|
||||||
# Image Docker officielle avec docker-compose
|
image: docker:27-cli
|
||||||
image: docker:latest
|
|
||||||
|
|
||||||
# Configuration Docker
|
|
||||||
environment:
|
|
||||||
DOCKER_HOST: unix:///var/run/docker.sock # Socket Docker du serveur Woodpecker
|
|
||||||
|
|
||||||
commands:
|
|
||||||
# Installation de docker-compose
|
|
||||||
- apk add --no-cache docker-compose
|
|
||||||
|
|
||||||
# Build de l'image Docker sans cache
|
|
||||||
# --no-cache : Force un rebuild complet (garantit que tout est à jour)
|
|
||||||
# docker-compose.business.yml : Fichier de configuration Docker Compose
|
|
||||||
- docker compose -f docker-compose.business.yml build --no-cache
|
|
||||||
|
|
||||||
# Démarrage du conteneur en mode détaché
|
|
||||||
# -d : Détaché (en arrière-plan)
|
|
||||||
# up : Crée et démarre les conteneurs
|
|
||||||
- docker compose -f docker-compose.business.yml up -d
|
|
||||||
|
|
||||||
# Vérification que le conteneur tourne
|
|
||||||
# Affiche les conteneurs contenant "laplank-radar" ou un message si non trouvé
|
|
||||||
- docker ps | grep laplank-radar || echo "Conteneur non trouvé"
|
|
||||||
|
|
||||||
# Volume pour accéder au socket Docker du serveur
|
|
||||||
# Nécessaire pour que le conteneur puisse utiliser Docker
|
|
||||||
volumes:
|
volumes:
|
||||||
- name: dockersock
|
- /var/run/docker.sock:/var/run/docker.sock
|
||||||
path: /var/run/docker.sock
|
commands:
|
||||||
|
- docker compose -f docker-compose.business.yml build --no-cache
|
||||||
|
- docker compose -f docker-compose.business.yml up -d --remove-orphans
|
||||||
|
- docker compose -f docker-compose.business.yml ps | grep laplank-radar || echo "Conteneur non trouve"
|
||||||
|
|
||||||
# Conditions de déclenchement (identique à deploy-rsync)
|
# Etape 3 : Notification Telegram
|
||||||
when:
|
|
||||||
branch:
|
|
||||||
- main
|
|
||||||
- stand-alone
|
|
||||||
event:
|
|
||||||
- push
|
|
||||||
|
|
||||||
# ============================================
|
|
||||||
# ÉTAPE 4: NOTIFICATION TELEGRAM
|
|
||||||
# ============================================
|
|
||||||
# Cette étape envoie une notification Telegram à la fin du pipeline
|
|
||||||
# Utile pour être informé immédiatement du résultat du build
|
|
||||||
- name: notify
|
- name: notify
|
||||||
# Plugin Drone/Woodpecker pour Telegram
|
|
||||||
# Compatible avec Woodpecker (fork de Drone)
|
|
||||||
image: appleboy/drone-telegram
|
image: appleboy/drone-telegram
|
||||||
|
|
||||||
# Configuration du plugin Telegram
|
|
||||||
settings:
|
settings:
|
||||||
token:
|
token:
|
||||||
from_secret: telegram_token # Token du bot Telegram
|
from_secret: telegram_token
|
||||||
to:
|
to:
|
||||||
from_secret: telegram_chat_id_ajr # ID du chat Telegram (destinataire)
|
from_secret: telegram_chat_id_ajr
|
||||||
format: markdown # Format du message (Markdown supporté)
|
format: markdown
|
||||||
|
|
||||||
# Message personnalisé avec template Woodpecker
|
|
||||||
# {{#success build.status}} : Condition si le build a réussi
|
|
||||||
# {{repo.name}} : Nom du dépôt Git
|
|
||||||
# {{commit.branch}} : Branche du commit
|
|
||||||
# {{commit.message}} : Message du commit
|
|
||||||
# {{commit.author}} : Auteur du commit
|
|
||||||
# {{build.link}} : Lien vers le build dans Woodpecker
|
|
||||||
message: >
|
message: >
|
||||||
{{#success build.status}}
|
{{#success build.status}}
|
||||||
✅ Build réussi pour `{{repo.name}}` sur la branche `{{commit.branch}}`
|
✅ Build réussi pour `{{repo.name}}` sur la branche `{{commit.branch}}`
|
||||||
@@ -214,32 +73,7 @@ steps:
|
|||||||
👤 Auteur: {{commit.author}}
|
👤 Auteur: {{commit.author}}
|
||||||
🔗 {{ build.link }}
|
🔗 {{ build.link }}
|
||||||
{{/success}}
|
{{/success}}
|
||||||
|
|
||||||
# Conditions de déclenchement
|
|
||||||
# S'exécute toujours, que le build réussisse ou échoue
|
|
||||||
when:
|
when:
|
||||||
status:
|
- status:
|
||||||
- success # Si le build réussit
|
- success
|
||||||
- failure # Si le build échoue
|
- failure
|
||||||
|
|
||||||
# ============================================
|
|
||||||
# VOLUMES TEMPORAIRES
|
|
||||||
# ============================================
|
|
||||||
# Ces volumes sont créés temporairement pour chaque pipeline
|
|
||||||
# Ils permettent de partager des données entre les étapes
|
|
||||||
volumes:
|
|
||||||
# Volume pour les node_modules de la racine
|
|
||||||
# Persiste entre les étapes pour éviter de réinstaller
|
|
||||||
- name: node_modules_root
|
|
||||||
temp: {} # Volume temporaire (supprimé à la fin du pipeline)
|
|
||||||
|
|
||||||
# Volume pour les node_modules de radar-app
|
|
||||||
# Persiste entre les étapes pour éviter de réinstaller
|
|
||||||
- name: node_modules_radar_app
|
|
||||||
temp: {}
|
|
||||||
|
|
||||||
# Volume pour accéder au socket Docker du serveur
|
|
||||||
# Nécessaire pour que les conteneurs puissent utiliser Docker
|
|
||||||
- name: dockersock
|
|
||||||
host:
|
|
||||||
path: /var/run/docker.sock # Chemin du socket Docker sur le serveur
|
|
||||||
|
|||||||
Reference in New Issue
Block a user