YYayaw

CI/CD

Comportement actuel des GitHub Actions et des déploiements.

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 un runner GitHub-hosted ubuntu-24.04-arm, 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 et DATABASE_URL nécessaires à next build.
  • 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 synchronisation de schéma drizzle-kit push 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.json désactive les déploiements Git Vercel avec git.deploymentEnabled: false; déconnectez aussi l'intégration Git Vercel dans le dashboard si Vercel ne doit plus publier de statuts PR externes.

Vercel possède le cycle build/deploy production quand le fournisseur Vercel est utilisé. Coolify possède les déploiements production auto-hébergés lorsque coolify-deploy.yml est configuré: 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. L'app Coolify de développement partagée bascule toujours sur la branche de PR afin de lire la définition Compose de la branche testée, mais le build Docker lourd tourne sur des runners Linux GitHub-hosted plutôt que sur la VM Mac mini. 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.

Vercel possède aussi les déploiements de prévisualisation et les commentaires de prévisualisation lorsque le fournisseur hébergé est activé. GitHub Actions ne doit pas ajouter de notifications de déploiement en double pour ce chemin.

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

Vercel et Docker auto-hébergé sont deux cibles supportées. Les variables d'environnement Vercel doivent être bornées comme Production, Preview ou Development. Les variables runtime auto-hébergées 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. 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 la synchronisation de schéma drizzle-kit push et le seed pour Coolify. 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:

EnvironnementNomUsage
development, productionBETTER_AUTH_SECRETRequis par le build Docker pour stabiliser l'évaluation des routes Better Auth.
development, productionDATABASE_URLURL de base build-time de repli pour l'évaluation des routes serveur.
development, productionvaleurs build NEXT_PUBLIC_*Configuration publique intégrée au bundle client Next.js.
development, productionvariable NEXT_BUILD_WORKERSNombre de workers de build. Défaut: 2.
development, productionvariable NEXT_STATIC_PAGE_GENERATION_TIMEOUTTimeout de génération statique. Défaut: 180.
development, productionvariables COOLIFY_SERVER_SSH_* ou secret COOLIFY_SERVER_SSH_KEYSurcharges optionnelles pour charger les images sur la VM Coolify. Les valeurs par défaut du runner Mac mini correspondent au setup SSH local de la VM.

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'une variable d'environnement Vercel, déclenchez un nouveau déploiement pour cet environnement. 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