CI/CD

Pipelines

Les workflows GitHub Actions vivent dans .github/workflows.

ci.yml

Jobs:

• Lint & Format Check: bun run check

• TypeScript Check: bun run docs:generate puis bunx tsc --noEmit

• Security Audit: bun run audit et bun run audit:dashboard

• Docs Integrity: vérification des liens docs et de la synchronisation LLM

CI est la barrière qualité des pull requests. Elle valide le formatage, la parité des docs générées, la sûreté TypeScript, les audits sécurité et l'intégrité documentaire avant merge.

coolify-deploy.yml

• S'exécute après la réussite de CI/CD Pipeline sur un push vers main.

• Peut aussi être lancé manuellement avec workflow_dispatch; l'entrée force reconstruit les images Docker sans le cache GitHub Buildx avant de déployer.

• Construit des images Docker immuables pour l'app et le worker sur le runner Docker Linux ARM64 auto-hébergé, cible linux/arm64 pour la VM Mac mini, pousse les images vers GHCR, puis laisse le runner auto-hébergé privé faire tirer ces images par la VM Coolify avant de déclencher le déploiement.

• Utilise le runner auto-hébergé dédié au dépôt, installé sur le Mac mini avec le label yayaw-coolify, pour les étapes API Coolify et SSH VM. Coolify reste ainsi accessible uniquement depuis le réseau privé Mac/Tailscale.

• Utilise l'environnement GitHub production et les secrets COOLIFY_URL, COOLIFY_API_TOKEN et COOLIFY_APPLICATION_UUID. L'environnement production stocke aussi les valeurs de compilation NEXT_PUBLIC_*, BETTER_AUTH_SECRET, SCIM_CREDENTIAL_HASH_SECRET et DATABASE_URL nécessaires à next build. Le secret SCIM atteint BuildKit uniquement via un montage de secret et n'est jamais persisté comme argument d'image ni variable d'environnement de couche.

• Sérialise les déploiements avec un groupe de concurrence dédié et interroge Coolify jusqu'à la fin ou l'échec du déploiement.

• Lance le service Compose migrate dans le réseau Coolify/Docker avant le démarrage de l'app et du worker, afin que la vérification du journal, le garde Better Auth 1.7, les migrations Drizzle versionnées et le seed atteignent les noms de services internes comme postgres.

• Smoke-teste la production après le signal de fin Coolify. Le test vérifie que /api/health expose le SHA mergé, que https://yayaw.app/fr répond et que les pages françaises Conditions d'utilisation et Politique de confidentialité rendent le contenu juridique lié à la page sans fuite de texte d'exemple de section réutilisable.

• Vercel n'est pas une cible de déploiement. vercel.json est conservé uniquement comme coupe-circuit avec git.deploymentEnabled: false; gardez le checkout non lié et déconnectez toute ancienne intégration Git Vercel.

coolify-rolling-deploy.yml

• Est un workflow de migration manuel, development d'abord; il ne remplace pas le déploiement Compose automatique avant validation des nouvelles ressources Coolify.

• Construit des images app et worker immuables avec une clé Server Actions partagée et un identifiant de déploiement Next.js dérivé du SHA du commit.

• Tire les images avec retry, vérifie le journal de migrations Drizzle et applique les migrations versionnées pendant que l'ancienne image web continue de servir.

• Met à jour une Application Coolify Docker Image avec healthchecks et sans port hôte, puis vérifie /api/ready depuis l'origine publique.

• Restaure le nom et le tag de l'image précédente si le déploiement ou le smoke public échoue. Les migrations restent appliquées et doivent donc être compatibles expand/contract.

Coolify possède les déploiements production : après la CI sur main, GitHub Actions construit et pousse les images Docker du commit mergé vers GHCR, les fait tirer par le serveur Coolify, met à jour YAYAW_APP_IMAGE et YAYAW_WORKER_IMAGE, puis demande à Coolify de lancer le déploiement Compose sans reconstruire sur la VM de production.

Le déploiement Compose auto-hébergé possède la synchronisation de schéma et le seed de production via son service migrate. Les changements de schéma doivent rester rétrocompatibles avec l'app actuellement déployée et le prochain déploiement.

YAYAW_APP_IMAGE et YAYAW_WORKER_IMAGE sont des variables Coolify à la fois runtime et build-time. Docker Compose interpole les valeurs image: pendant la préparation du déploiement Coolify, avant le démarrage des conteneurs.

Les déploiements de développement des pull requests utilisent le même chemin d'images précompilées après la CI. Le workflow force la branche technique coolify/development du dépôt vers le SHA de tête de la pull request, pointe l'app Coolify partagée sur cette branche stable et garde la ref PR d'origine dans les métadonnées de déploiement. Coolify peut ainsi cloner le dépôt même si GitHub supprime la branche source juste après le merge. Les workflows utilisent GHCR comme transport d'images au lieu des artifacts GitHub Actions; les déploiements de développement et production ne dépendent donc pas du quota de stockage artifacts.

Les prévisualisations utilisent le même chemin Docker/GHCR/Coolify. N'ajoutez aucun workflow de déploiement ou commentaire de prévisualisation Vercel.

Flux De Branche Et Pull Request

Utilisez une branche par tâche:

git checkout main
git pull --ff-only origin main
git checkout -b codex/<task-name>

Avant d'ouvrir une PR:

1. Gardez le diff limité à la tâche.

2. Stagez uniquement les fichiers voulus.

3. Commitez avec un résumé court.

4. Poussez la branche.

5. Ouvrez une draft PR sauf demande explicite de revue prête.

Les fichiers générés sont attendus lorsque leur source change:

• AGENTS.md

• GEMINI.md

• .github/copilot-instructions.md

• actions serveur Drizzle générées lorsque les schémas changent

• artefacts source Fumadocs lorsque le contenu docs change

Commandes De Parité Locale

bun run check
bun run docs:generate
bun run docs:check-links
bun run docs:check-translations
bun run docs:llm:check
bunx tsc --noEmit
bun run build

Pour les travaux facturation, webhooks ou accès au code, lancez aussi:

bun run test

Pour les changements d'actions générées:

bun run generate:actions

Pour les changements de docs assistants:

bun run docs:llm:generate

Environnements De Déploiement

Docker/Coolify est la cible de déploiement supportée. Les variables runtime vivent dans le magasin de secrets de l'orchestrateur ou dans le fichier non suivi .env.self-host utilisé par docker-compose.self-host.yml. Ne liez pas ce checkout à Vercel et n'ajoutez aucun workflow de déploiement Vercel. Voir Configuration de l'environnement de déploiement et Auto-hébergement pour la récupération des valeurs fournisseur et les vérifications de déploiement.

Le service Compose auto-hébergé migrate possède les migrations Drizzle versionnées, le seed et la réparation du stockage dynamic-data déployé pour Coolify. La migration 0050 sur une base existante exige aussi le blocage externe documenté des écritures /api/auth et l'attestation opérateur temporaire BETTER_AUTH_17_WRITES_PAUSED=true. Gardez le DATABASE_URL de l'environnement GitHub production disponible pour l'évaluation des routes serveur au build time, mais ne lancez pas un workflow de migration production séparé à côté du déploiement Compose.

Le flux Coolify avec images précompilées requiert ces secrets ou variables GitHub bornés par environnement:

Les workflows accordent packages: write au job de build d'images et packages: read au job de déploiement Coolify pour que le GITHUB_TOKEN du dépôt puisse pousser les images immuables vers GHCR et que le runner auto-hébergé puisse les tirer sur la VM.

Après modification d'un secret auto-hébergé, redémarrez les conteneurs app ou worker concernés et vérifiez le statut de déploiement dans /dashboard/admin.

Sécurité De Merge

L'auto-merge ne s'exécute que lorsque les checks requis ont réussi.

Ne contournez pas les échecs d'intégrité documentaire. Ils signalent généralement:

• un lien interne de documentation cassé

• une modification de content/llm/llm-source.md sans régénération des fichiers assistants

• des artefacts docs générés obsolètes