Intégration continue

L'intégration continue tourne sur GitHub Actions avec deux workflows :

• .github/workflows/ci.yml : contrôles de chaque projet, intégration sur une vraie blockchain locale, images Docker ;
• .github/workflows/codeql.yml : analyse statique de sécurité du JavaScript et du TypeScript.

Les deux se déclenchent à chaque pull request et à chaque push sur main. ci.yml peut aussi être lancé à la main (workflow_dispatch) ; codeql.yml tourne en plus chaque lundi à 3 h 17 UTC (cron: '17 3 * * 1'), pour détecter les nouvelles règles ou vulnérabilités sur un code qui n'a pas bougé.

#Vue d'ensemble

flowchart LR
    CH["changes"] --> BE["backend"]
    CH --> SC["contracts"]
    CH --> WEB["web"]
    CH --> MOB["mobile"]
    CH --> TOU["tourisme"]
    BE --> CHAIN["chain"]
    SC --> CHAIN
    BE --> DOCK["docker"]
    SC --> DOCK
    WEB --> DOCK
    TOU --> DOCK
    SEC["secrets (gitleaks)"]

Le job secrets ne dépend de rien et tourne toujours. Les autres ne tournent que si le projet qu'ils contrôlent a changé.

#Principes communs

#Secrets

La CI n'utilise aucun secret de dépôt : aucun ${{ secrets.* }} n'apparaît dans les workflows. Les bases de données des jobs sont des conteneurs de service éphémères avec des identifiants ci/ci, et le nœud Hardhat utilise ses comptes de test publics. Les tests du backend ne lisent donc que des valeurs de développement, que le schéma de configuration refuserait en production.

À l'inverse, la CI cherche des secrets dans le code :

• le job secrets lance gitleaks sur tout l'historique Git ;
• le job web vérifie qu'aucun secret ni source map ne se trouve dans le bundle public.

Le fichier .gitleaks.toml étend les règles par défaut de gitleaks et n'autorise que deux valeurs : la clé de développement ENCRYPTION_KEY (0123…cdef) et la clé privée du compte Hardhat n° 0. Toutes deux sont publiques et refusées par le backend en production.

#Détection des projets modifiés

Le job changes utilise dorny/paths-filter. Sur une pull request, il compare la branche à sa base ; sur un push, au commit précédent. Il expose une sortie booléenne par filtre :

Chaque filtre inclut aussi .github/workflows/ci.yml : une modification du workflow relance tous les jobs. La documentation (documentation-officielle/, docs/) et load-tests/ ne déclenchent aucun job de contrôle, seulement secrets et CodeQL.

#Les jobs de ci.yml

#backend

Conteneurs de service postgres:15-alpine et redis:7.4-alpine, avec sondes de santé. Étapes, depuis backend/ :

1. npm ci ;
2. npm audit --omit=dev --audit-level=high : échec sur une vulnérabilité haute ou critique d'une dépendance de production ;
3. npx prisma generate ;
4. npm run env:check : check-env-example.mjs vérifie que .env.example contient exactement les variables du schéma ;
5. npm run typecheck et npm run lint ;
6. npx prisma migrate deploy sur une base vierge : chaque migration doit s'appliquer depuis zéro ;
7. npx prisma migrate diff --from-config-datasource --to-schema prisma/schema.prisma --exit-code : échec si schema.prisma a changé sans migration correspondante ;
8. npm test -- --ci ;
9. npm run compile : le build de production réussit.

#contracts

Lancé si smart-contract/ ou backend/ a changé, car le backend embarque les ABI des contrats. Depuis smart-contract/ :

1. npm audit --omit=dev --audit-level=critical : seuil critique seulement, justifié dans l'ADR 0004. Les alertes hautes viennent des dépendances transitives de @chainlink/contracts (sources OpenZeppelin 4.x non importées, outillage JavaScript), qui ne sont ni dans le bytecode déployé, ni exécutées par le backend ;
2. npm run typecheck (compilation Hardhat puis tsc --noEmit) ;
3. npm run lint : solhint avec zéro avertissement toléré ;
4. npm run test:coverage : tests unitaires et fuzzing avec couverture ;
5. npm run coverage:check : 100 % des lignes des contrats de production ;
6. node scripts/export-abi.mjs --check : les ABI copiées dans backend/src/blockchain/abi/ correspondent aux contrats compilés ;
7. npm run slither : analyse statique Slither, échec dès le niveau Medium.

Le détail de ces contrôles est dans Tests, fuzzing et couverture.

#chain

Intégration du backend contre une vraie blockchain. Il dépend de changes, contracts et backend, avec la condition :

if: >-
  always() && !failure() && !cancelled() &&
  (needs.changes.outputs.contracts == 'true' || needs.changes.outputs.backend == 'true')

always() force l'évaluation même si un job requis a été sauté (par exemple backend quand seuls les contrats changent) ; !failure() l'empêche de tourner si l'un d'eux a échoué.

1. Construction de l'image smart-contract et démarrage du conteneur blocklucky-chain sur le port 8545 ;
2. attente de l'état healthy (60 essais espacés de 3 secondes, journaux du nœud affichés en cas d'échec) ;
3. npm ci, npx prisma generate, npx prisma migrate deploy dans backend/ ;
4. npm run test:chain -- --ci : la configuration jest.chain.config.json lance les scénarios d'achat, de cadeau, de tirage VRF, de versement de la cagnotte et de disjoncteur sur la chaîne ;
5. en cas d'échec, docker logs blocklucky-chain.

Voir Tests sur une vraie chaîne.

#web

Depuis frontend-web/ : npm audit --omit=dev --audit-level=high, npm run lint, npm run typecheck, npm test (Vitest), puis npm run build avec le cache .next/cache restauré par actions/cache. Le build est suivi de deux contrôles sur .next/static, le dossier servi aux navigateurs :

• aucune chaîne ne ressemble à une clé Stripe live (sk_live_), à une clé d'accès AWS (AKIA…), à un bloc PRIVATE KEY ou à la clé privée du compte Hardhat n° 0 ;
• aucun fichier .map n'est présent.

#mobile

Depuis mobile-app/ : npm audit --omit=dev --audit-level=high, npm run typecheck, npm run lint et npx expo config --type public, qui échoue si la configuration Expo est invalide. Aucun build natif n'est lancé en CI.

#tourisme

Le site n'a pas de dépendances npm. Le job vérifie la syntaxe de chaque module de assets/js avec node --check, puis lance check-static-links.mjs, qui contrôle que chaque ressource locale référencée par les pages HTML existe.

#docker

Il dépend de changes, backend, contracts, web et tourisme, avec la même logique always() && !failure() && !cancelled(), et tourne dès qu'un des projets conteneurisés ou l'infrastructure a changé.

1. docker compose --profile app config -q : validation du fichier Compose ;
2. construction avec Buildx des images backend (cible runtime), web, blockchain et Office de Tourisme, chargées localement (load: true, push: false) avec un cache GitHub Actions par image (type=gha, un scope par image) ;
3. analyse Trivy des images backend, web et tourisme (vulnérabilités CRITICAL et HIGH corrigeables).

Aucune image n'est publiée dans un registre. Voir Images Docker.

#secrets

gitleaks en version v8.30.1, lancé dans Docker sur le dépôt cloné avec tout son historique (fetch-depth: 0), en mode --redact : un secret trouvé n'est pas recopié en clair dans les journaux de la CI.

#CodeQL

Le workflow codeql.yml analyse le code JavaScript et TypeScript de tout le dépôt avec la suite de requêtes security-extended, qui ajoute à la suite par défaut des requêtes de sécurité de précision moindre. Il ignore node_modules, les dossiers __tests__ et les bibliothèques tierces de frontend-office-tourisme/assets/js/vendor/. Les résultats apparaissent dans l'onglet Security du dépôt GitHub (droit security-events: write).

Le Solidity n'est pas couvert par CodeQL : il l'est par solhint et Slither dans le job contracts.

#Référence générée

La liste ci-dessous est produite depuis les fichiers de workflow à chaque construction de la documentation.

#Workflow ci.yml : CI

Déclencheurs : pull_request, push, workflow_dispatch.

#Détection des projets modifiés

Identifiant changes, délai maximal 5 minutes.

1. action actions/checkout
2. action dorny/paths-filter

#Recherche de secrets (gitleaks)

Identifiant secrets, délai maximal 10 minutes.

1. action actions/checkout
2. Historique Git complet

#Documentation officielle (génération, liens, fraîcheur)

Identifiant documentation, délai maximal 10 minutes.

1. action actions/checkout
2. action actions/setup-node
3. npm ci
4. Pages générées depuis le code à jour, liens et ancres valides, descriptions complètes

#Backend (typecheck, lint, tests, migrations)

Identifiant backend, après changes, délai maximal 15 minutes.

1. action actions/checkout
2. action actions/setup-node
3. npm ci
4. Vulnérabilités hautes et critiques des dépendances de production
5. npx prisma generate
6. Synchronisation de .env.example avec le schéma de configuration
7. npm run typecheck
8. npm run lint
9. Migrations appliquées sur une base vierge
10. Absence de dérive entre le schéma Prisma et les migrations
11. npm test -- --ci
12. npm run compile

#Smart contracts (lint, tests, couverture, Slither)

Identifiant contracts, après changes, délai maximal 20 minutes.

1. action actions/checkout
2. action actions/setup-node
3. npm ci
4. Vulnérabilités critiques des dépendances des contrats (voir ADR 0004)
5. npm run typecheck
6. Règles Solidity (solhint, zéro avertissement)
7. Tests unitaires, fuzzing et couverture
8. Couverture des lignes des contrats de production à 100 %
9. ABI embarquées par le backend à jour
10. Analyse statique (Slither, échec dès le niveau Medium)

#Intégration backend sur une vraie blockchain locale

Identifiant chain, après changes, contracts, backend, délai maximal 20 minutes.

1. action actions/checkout
2. Nœud Hardhat, contrats déployés et oracle VRF local
3. action actions/setup-node
4. npm ci
5. npx prisma generate
6. npx prisma migrate deploy
7. Achat, cadeau, tirage VRF, versement de la cagnotte et disjoncteur sur la chaîne
8. Journaux du nœud en cas d'échec

#Frontend web (lint, typecheck, tests, build)

Identifiant web, après changes, délai maximal 15 minutes.

1. action actions/checkout
2. action actions/setup-node
3. npm ci
4. Vulnérabilités hautes et critiques des dépendances de production
5. npm run lint
6. npm run typecheck
7. npm test
8. action actions/cache
9. npm run build
10. Aucun secret ni source map dans le bundle public

#Application mobile (typecheck, lint)

Identifiant mobile, après changes, délai maximal 15 minutes.

1. action actions/checkout
2. action actions/setup-node
3. npm ci
4. Vulnérabilités hautes et critiques des dépendances de production
5. npm run typecheck
6. npm run lint
7. Vérification de la configuration Expo

#Site Office de Tourisme (syntaxe et liens)

Identifiant tourisme, après changes, délai maximal 5 minutes.

1. action actions/checkout
2. action actions/setup-node
3. Syntaxe des modules JavaScript
4. Ressources locales référencées par les pages HTML

#Images Docker et Compose

Identifiant docker, après changes, backend, contracts, web, tourisme, délai maximal 20 minutes.

1. action actions/checkout
2. Validation de docker-compose.yml
3. action docker/setup-buildx-action
4. Image backend
5. Image frontend web
6. Image blockchain locale
7. Image Office de Tourisme
8. Vulnérabilités des images (Trivy)

#Workflow codeql.yml : CodeQL

Déclencheurs : pull_request, push, schedule.

#Analyse statique JavaScript et TypeScript

Identifiant analyze, délai maximal 30 minutes.

1. action actions/checkout
2. action github/codeql-action/init
3. action github/codeql-action/analyze

#Lire un échec

Les règles de branche et de revue qui s'appuient sur ces jobs sont décrites dans Workflow Git.