# Déployer depuis GitHub

L’intégration GitHub construit ton site dans GitHub Actions, sur les minutes de ton compte, et publie le résultat. Chaque push sur la branche principale part en production. Chaque autre branche reçoit une preview.

**Résultat attendu** : un push déclenche un build visible dans Host, avec sa sortie en direct, puis un déploiement **Prêt**.

**Avant de commencer** : un dépôt où tu as le droit d’écriture, et un site qui se construit avec une commande de build.

## Importer un dépôt

1. **Installe l'app GitHub**

   Dans **Nouveau projet**, choisis **Importer depuis GitHub** et installe l’app **Host** sur ton compte GitHub ou sur celui de ton organisation. Tu peux la restreindre à certains dépôts.

   Host s’en sert pour lire la liste des dépôts, ouvrir la pull request d’installation et déclencher les builds.

2. **Choisis le dépôt**

   Seuls les dépôts où tu peux pousser apparaissent. Un dépôt où tu n’as que la lecture ne s’importe pas : l’import ouvre une pull request et pose un secret dans le dépôt.

3. **Vérifie les réglages détectés**

   Host propose le framework, les commandes d’installation et de build, la version de Node.js et la branche de production. Corrige ce qui ne correspond pas avant de continuer.

   Pour un site dans un sous-dossier, voir [Monorepo et sous-dossier](/docs/guides/monorepo/).

4. **Fusionne la pull request**

   L’import ouvre une pull request qui ajoute `.github/workflows/hgdc-host.yml` et pose le secret `HGDC_HOST_TOKEN`.

   **Vérification** : une fois la PR fusionnée, un push sur la branche principale déclenche un build.

## Ce que fait le workflow

1. Il annonce le build à Host. Le déploiement apparaît dans la console dès le début, avec sa sortie en direct.
2. Il restaure le cache du run précédent : `node_modules` tant que ton fichier de verrouillage ne change pas, le cache de ton framework et la CLI Vercel.
3. Il lance `vercel pull` pour récupérer les réglages et les variables, puis `vercel build`.
4. Il envoie le résultat avec `vercel deploy --prebuilt`, avec `--prod` sur la branche de production.
5. En cas d’échec ou d’annulation, il le signale. Le déploiement passe à **Erreur** ou **Annulé**.

Deux pushes sur la même branche : le premier build est annulé au profit du second. Le premier build d’une branche remplit le cache, les suivants vont plus vite.

Pour repartir d’un cache propre, supprime les caches `hgdc-host-*` dans l’onglet **Actions** du dépôt.

## Déployer sans pousser

Dans Host, deux actions relancent un build sans nouveau commit :

- **Déployer en production** lance le workflow sur la branche de production.
- **Redéployer**, sur un déploiement, reconstruit le même commit avec les variables d’aujourd’hui.

Le build passe par GitHub Actions, comme pour un push.

## Mettre le workflow à jour

Quand Host fait évoluer son workflow, l’onglet **Git** du projet propose **Mettre à jour le workflow**. Host ouvre une pull request qui remplace le fichier. Fusionne-la, puis déploie.

## Débrancher le dépôt

Dans l’onglet **Git**, **Débrancher** révoque la clé posée dans le dépôt. Les pushes suivants n’arrivent plus à Host. Supprime ensuite le fichier `.github/workflows/hgdc-host.yml` du dépôt. Les dépôts branchés avant le changement de nom gardent `.github/workflows/smartflow-host.yml` et le secret `SMARTFLOW_HOST_TOKEN` : ils continuent de fonctionner, sans rien changer de ton côté.

Les variables du projet restent en place, devenues manuelles. Aucun build ne les perd d’un coup.

> **Astuce**
>
> Tu préfères écrire ton propre workflow ? Voir [GitHub Actions sans l’application](/docs/guides/github-actions-sans-application/).

## Si ça ne marche pas

Voir [Dépannage](/docs/guides/depannage/#le-build-github-est-absent) pour le build qui n’apparaît pas, et la sortie du run dans l’onglet **Actions** du dépôt pour le build qui échoue.