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.

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.

Tu préfères écrire ton propre workflow ? Voir GitHub Actions sans l’application.

Si ça ne marche pas

Voir Dépannage 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.