GitHub workflows

Statut

Document de cadrage DevOps — version initiale — v1.0 — relu le 2026-05-11.

Objectif

Les workflows GitHub doivent automatiser les contrôles répétitifs : lint, tests, build, sécurité de base et éventuellement déploiement.

Ils doivent rester lisibles et alignés avec l'organisation réelle du workspace.

État actuel — Workflow opérationnel

Le fichier .github/workflows/deploy.yml est actif sur le dépôt api.

Il se déclenche sur push vers main et sur workflow_dispatch.

on:
  push:
    branches: [main]
  workflow_dispatch:

Secrets requis

Secret	Usage
SSH_HOST	Adresse IP ou hostname du VPS
SSH_PRIVATE_KEY	Clé privée SSH pour l'utilisateur deploy

Points de vigilance implémentés

• La racine du dépôt api est directement le projet Laravel (pas de sous-dossier) — aucun working-directory ne doit être configuré dans les steps.
• Le service PostgreSQL CI requiert DB_SSLMODE=disable (pas de TLS sur le service local GitHub Actions).
• L'APP_KEY est généré dynamiquement à chaque run de test via php -r 'echo base64_encode(random_bytes(32));'.

Workflows cibles

Workflow	Déclenchement	Rôle
Backend CI	Pull request et push	Composer, tests Laravel, qualité PHP.
Public frontend CI	Pull request et push	Installation, lint, build Next.js.
Backoffice CI	Pull request et push	Installation, lint, build Vite.
Docs check	Pull request docs	Liens, format Markdown si outillage retenu.
Deploy staging	Push branche staging	Déploiement environnement de test.
Deploy production	Release ou validation manuelle	Déploiement contrôlé.

Secrets GitHub

Les secrets GitHub doivent être limités et nommés clairement :

• clé SSH de déploiement ;
• host de déploiement ;
• utilisateur de déploiement ;
• tokens de registry si nécessaire ;
• variables provider frontend si utilisées ;
• webhook de notification si retenu.

Les secrets applicatifs complets ne doivent pas être dispersés inutilement dans GitHub si le serveur peut les conserver dans .env.

Principes

• Un workflow doit avoir un objectif unique.
• Les étapes doivent être reproductibles localement.
• Les déploiements production doivent être protégés.
• Les logs ne doivent pas afficher de secrets.
• Les versions des actions doivent être figées.
• Les builds doivent utiliser les lockfiles.

Contrôles recommandés

• composer install ;
• php artisan test si environnement prêt ;
• vendor/bin/pint --test si standard actif ;
• npm ci ;
• npm run lint ;
• npm run build ;
• vérification d'absence de secrets évidents ;
• validation des fichiers de déploiement.

Points restants à clarifier

• Règles de protection de branche main (revue obligatoire, status checks).
• Workflow pour les frontends (dmv-public, dmv-backoffice).
• Notifications de succès/échec (Slack ou autre).