CI/CD

Explainer utilise un seul workflow GitHub Actions pour le déploiement continu. Les trois applications (Docs, Blog, Website) sont gérées dans un workflow unifié avec une détection intelligente des changements.

Fichier du workflow

Fichier	Applications	Déclencheurs
`.github/workflows/deploy.yml`	Docs, Blog, Website	`push` sur `main`, `workflow_dispatch`

Modes de déclenchement

Le workflow prend en charge deux modes de déclenchement :

Push sur main — ne compile et déploie que les applications affectées par les fichiers modifiés (filtrage basé sur les chemins)
Manuel (workflow_dispatch) — permet de sélectionner les applications à déployer via des cases à cocher

on:
  push:
    branches: [main]
  workflow_dispatch:
    inputs:
      docs:
        description: 'Deploy Docs'
        type: boolean
        default: true
      blog:
        description: 'Deploy Blog'
        type: boolean
        default: true
      website:
        description: 'Deploy Website'
        type: boolean
        default: true

Détection des changements

Un job changes utilise dorny/paths-filter pour détecter quelles applications doivent être reconstruites :

Application	Se déclenche lors de modifications sur
Docs	`apps/docs/`, `packages/`, `pnpm-lock.yaml`
Blog	`apps/blog/`, `packages/`, `pnpm-lock.yaml`
Website	`apps/website/`, `packages/`, `pnpm-lock.yaml`

Les modifications sur packages/** déclenchent la compilation de toutes les applications. C’est intentionnel — les paquets partagés comme @explainer/ui ou @explainer/mdx affectent toutes les applications, elles doivent donc toutes être reconstruites et redéployées.

Schéma de compilation et déploiement

Chaque application suit un schéma en deux étapes : compilation puis déploiement. Les jobs de compilation s’exécutent en parallèle lorsque plusieurs applications sont affectées.

build-docs:
  needs: changes
  if: needs.changes.outputs.docs == 'true' || (github.event_name == 'workflow_dispatch' && inputs.docs)
  steps:
    - uses: actions/checkout@v4
    - uses: pnpm/action-setup@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 22
        cache: 'pnpm'
    - run: pnpm install --frozen-lockfile
    - run: pnpm --filter @explainer/docs build
      env:
        PUBLIC_WEBSITE_URL: ${{ vars.PUBLIC_WEBSITE_URL }}
        PUBLIC_DOCS_URL: ${{ vars.PUBLIC_DOCS_URL }}
        PUBLIC_BLOG_URL: ${{ vars.PUBLIC_BLOG_URL }}
    - uses: actions/upload-artifact@v4
      with:
        name: docs-dist
        path: apps/docs/dist/

Les artefacts compilés sont téléversés puis consommés par le job de déploiement.

Variables d’environnement et secrets

Variables publiques

Celles-ci sont nécessaires pour les liens de navigation entre applications. Définissez-les dans GitHub Settings → Variables :

Variable	Description	Exemple
`PUBLIC_WEBSITE_URL`	URL de l’application Website	`https://explainer.dev`
`PUBLIC_DOCS_URL`	URL de l’application Docs	`https://docs.explainer.dev`
`PUBLIC_BLOG_URL`	URL de l’application Blog	`https://blog.explainer.dev`
`DEPLOY_TARGET`	Plateforme de déploiement	`cloudflare`

Les trois variables PUBLIC_* sont transmises à chaque compilation d’application. Cela garantit que les liens de la barre de navigation entre les applications pointent toujours vers les bonnes URL, quelle que soit la plateforme de déploiement.

Secrets

Type	Nom	Utilisé par
Secret	`CLOUDFLARE_API_TOKEN`	Cloudflare
Secret	`CLOUDFLARE_ACCOUNT_ID`	Cloudflare
Secret	`VERCEL_TOKEN`	Vercel
Secret	`VERCEL_ORG_ID`	Vercel
Secret	`VERCEL_DOCS_PROJECT_ID`	Vercel (docs)

GitHub Pages utilise les permissions intégrées du GITHUB_TOKEN — aucun secret supplémentaire n’est nécessaire.

Schéma DEPLOY_TARGET

Le workflow utilise une variable de dépôt DEPLOY_TARGET pour sélectionner la plateforme de déploiement :

deploy-docs:
  needs: build-docs
  if: vars.DEPLOY_TARGET == 'cloudflare'
  # ...

Définissez DEPLOY_TARGET une seule fois dans les variables de votre dépôt et le bon job de déploiement s’exécutera automatiquement.