Git Deploy

L'onglet Git Deploy du Portail relie votre serveur à un dépôt Git sur GitHub, GitLab, Gitea ou Forgejo. Ses fichiers sont copiés sur votre serveur automatiquement — à chaque push, lorsque vous publiez une release, lorsque vous poussez un tag, ou d'un simple clic. Si vous le souhaitez, votre serveur est arrêté proprement avant le déploiement, puis redémarré ensuite.

En bref : poussez votre code, et quelques secondes plus tard il tourne sur votre serveur. Plus besoin de téléverser via SFTP, de décompresser des fichiers ZIP dans le gestionnaire de fichiers, ni d'oublier de redémarrer.

Ce que vous allez apprendre

• Comment connecter un dépôt, avec l'app GitHub Daki Git Deploy ou avec un token d'accès
• Quand un déploiement a lieu et comment en lancer un vous-même
• Comment protéger mondes, bases de données et fichiers .env grâce aux chemins protégés
• Comment fonctionnent les redémarrages, l'historique des déploiements, les retours arrière et le statut dans votre dépôt
• Comment donner les bonnes permissions à votre équipe

Pour qui

• Développeurs de bots Discord et d'apps Node.js, Python ou Java dont le code est déjà sur GitHub ou GitLab.
• Réseaux Minecraft et équipes de serveurs de jeu qui gardent plugins, configurations ou datapacks dans un dépôt et veulent que les changements se déploient de façon traçable.
• Équipes : plusieurs personnes travaillent sur le dépôt, le serveur est toujours à jour, et les permissions des sous-utilisateurs décident précisément qui peut déployer.
• Projets basés sur les releases : seules les versions publiées (par exemple un .jar finalisé issu d'une release) arrivent sur le serveur, et non chaque travail en cours.

Avant de commencer

• Un serveur dans le Portail qui affiche l'onglet Git Deploy. Il se trouve dans la navigation du serveur, sous Essentials, juste après Files par défaut.
• Un dépôt sur GitHub (github.com), GitLab (gitlab.com ou votre propre instance, sous-groupes comme group/subgroup/project inclus), Gitea ou Forgejo (par exemple Codeberg ou votre propre instance). Les dépôts publics comme privés fonctionnent.

Démarrage rapide avec GitHub (recommandé)

La méthode la plus rapide : connectez-vous avec Daki Git Deploy, l'app GitHub officielle de Daki Hosting. Vous vous connectez sur GitHub et choisissez vos dépôts — aucun token ni aucun webhook n'est nécessaire.

1. 1

   Ouvrir l'onglet Git Deploy

   Dans le Portail, ouvrez votre serveur et rendez-vous dans l'onglet Git Deploy. Sous Git service, choisissez GitHub.

2. 2

   Connecter votre compte GitHub

   Dans l'encadré GitHub access, cliquez sur Connect with GitHub. Connectez-vous sur GitHub et autorisez l'app.

   La première fois, GitHub vous amène ensuite directement au choix des dépôts auxquels l'app peut accéder (All repositories ou uniquement les dépôts sélectionnés) — en une seule étape au lieu de deux. Ensuite, vous revenez dans le Portail, et l'encadré GitHub access affiche Connected via Daki Git Deploy as suivi de votre nom GitHub. L'encadré Webhook confirme qu'il n'y a rien à configurer : les push et les releases arrivent par l'app toutes seules.

3. 3

   Choisir votre dépôt et votre branche

   Cliquez sur Choose from my repositories et sélectionnez votre dépôt, ou collez son URL web ou de clonage, ou saisissez le chemin. Cliquez sur Load branches et choisissez la branche à déployer. Laissez le champ de branche vide pour utiliser la branche par défaut du dépôt.

4. 4

   Choisir quand et comment déployer

   Sous When to deploy, choisissez un mode (par exemple Every push). Définissez ensuite le dossier cible, vos chemins protégés et le comportement au redémarrage.

5. 5

   Enregistrer

   Cliquez sur Save settings dans la barre en bas. C'est tout : l'en-tête de l'onglet affiche Automatic deploys on, et votre prochain push sera déployé automatiquement. Pour déployer tout de suite, cliquez sur Deploy now en haut à droite.

• Autoriser un autre dépôt : Choose repositories on GitHub rouvre la sélection des dépôts sur GitHub, où vous choisissez les dépôts auxquels Daki Git Deploy peut accéder.
• Supprimer la connexion : cliquez sur Disconnect. Le serveur ne déploie alors plus depuis les dépôts privés.

Démarrage rapide avec un token d'accès

Pour GitLab, Gitea et Forgejo — et pour GitHub si vous le préférez — vous enregistrez un token d'accès personnel. Les dépôts publics fonctionnent sans aucun token.

1. 1

   Choisir le service Git

   Ouvrez votre serveur → Git Deploy et choisissez le Git service. Pour votre propre instance GitLab, Gitea ou Forgejo, saisissez l'URL du serveur (par exemple https://codeberg.org ou https://git.example.com). Pour gitlab.com, laissez ce champ vide.

2. 2

   Saisir le dépôt

   Saisissez le dépôt sous forme de chemin (owner/name) ou collez simplement son URL web ou de clonage. Pour un dépôt public, c'est tout ce qu'il faut — sans token, la zone d'accès affiche No token – public repositories only.

3. 3

   Enregistrer un token pour les dépôts privés

   Avec GitHub, cliquez d'abord sur Use an own access token instead dans la zone GitHub access. Puis créez un token chez votre fournisseur Git — le lien Create a token on … du Portail vous mène directement à la bonne page — et enregistrez-le sous Personal access token. Le Portail vérifie le token immédiatement. Voir Permissions du token pour les droits nécessaires.

4. 4

   Choisir vos paramètres et enregistrer

   Choisissez quand déployer, le dossier cible, les chemins protégés et le comportement au redémarrage, puis cliquez sur Save settings.

5. 5

   Ajouter le webhook

   L'encadré Webhook affiche la Payload URL et le Secret, chacun avec un bouton de copie. Ajoutez-les à votre dépôt comme décrit dans Configurer le webhook. Sous l'encadré, Last delivery indique ensuite si le webhook arrive.

6. 6

   Activer les déploiements automatiques

   Activez Automatic deploys active.

Permissions du token

Si seule l'autorisation d'écriture pour le statut manque, votre serveur est tout de même déployé — le journal de déploiement affiche une remarque.

Configurer le webhook

Quand un déploiement a lieu

Sous When to deploy, choisissez l'un des quatre modes :

Déclencheurs

• Webhook : votre fournisseur Git signale les changements immédiatement, et le déploiement démarre en quelques secondes. Avec l'app GitHub, cela se fait automatiquement, sans webhook de votre part.
• Vérifications de mises à jour (polling) : facultatives, pour les cas où votre fournisseur Git ne peut pas joindre le Portail. Intervalles de 5 minutes à 1 jour.
• Deploy now : à tout moment, d'un simple clic. En mode release, vous pouvez choisir une release précise.
• Ignorer un push : mettez [skip deploy] dans le message de commit et ce push n'est pas déployé. [deploy skip] et [no deploy] fonctionnent aussi.

Attendre les vérifications CI

Lorsque Wait for CI checks est activé (uniquement en mode Every push), un commit n'est déployé qu'une fois que sa CI est au vert — GitHub Actions, GitLab CI et Gitea/Forgejo Actions sont pris en charge. Si la CI échoue, le déploiement est ignoré.

Tous les paramètres expliqués

Les modifications ne prennent effet qu'après un clic sur Save settings. Tant que quelque chose n'est pas enregistré, une barre en bas affiche Discard et Save settings, et Deploy now est verrouillé.

Remove files that were deleted from the repository ne supprime que les fichiers qu'un déploiement précédent a écrits lui-même — jamais les chemins protégés, ni les fichiers que vous avez créés vous-même. Les dossiers vides restent en place.

Chemins protégés

Les fichiers et dossiers listés sous Protected paths ne sont jamais écrasés ni supprimés par un déploiement. S'ils n'existent pas encore, ils sont créés une seule fois. Idéal pour les mondes de jeu, les bases de données et les mots de passe.

Écrivez une règle par ligne, par rapport au dossier cible. Les lignes vides et les lignes commençant par # sont ignorées. * ne correspond jamais au-delà d'un /.

Exemples typiques :

world/
world_nether/
world_the_end/
plugins/*/config.yml
whitelist.json
ops.json
banned-*.json

.env
*.db
*.sqlite
node_modules/
data/

.env
*.db
venv/

Comportement au redémarrage

If the server does not stop: certains programmes, en particulier les apps Node.js, ignorent le signal d'arrêt. Le serveur est alors arrêté de force après le délai choisi (immédiatement, de 5 secondes à 5 minutes ; Kill after 10 seconds par défaut) pour que le déploiement ne reste pas bloqué. L'arrêt forcé immédiat est le plus rapide, mais ne laisse aucun délai au serveur pour enregistrer ses données.

Déroulement d'un déploiement

1. Un déclencheur (push, release, tag, vérification de mise à jour ou bouton) crée un déploiement.
2. Si Wait for CI checks est activé, il attend que les vérifications CI soient au vert (Waiting).
3. Le Portail télécharge l'archive depuis votre fournisseur Git. Vos identifiants ne quittent jamais le Portail et n'arrivent jamais sur votre serveur.
4. L'archive est préparée : seul le dossier choisi est conservé, les chemins protégés sont filtrés et les contenus non sûrs, comme les liens symboliques, sont écartés.
5. Selon vos paramètres, le serveur est arrêté (et arrêté de force après le délai choisi si nécessaire).
6. Les fichiers sont écrits dans le dossier cible ; éventuellement, les fichiers supprimés sont retirés.
7. Selon vos paramètres, le serveur est redémarré.
8. Le résultat et le journal complet apparaissent dans l'historique — et, si c'est activé, sous forme de statut sur le commit.

Un déploiement prend généralement 10 à 40 secondes, auquel s'ajoute le temps nécessaire à l'arrêt de votre serveur.

Historique, journaux et rollback

La liste Deployments en bas de l'onglet affiche chaque déploiement avec son statut, sa branche et son commit (par exemple main @ 75cd0a1), son numéro, son déclencheur, la personne qui l'a lancé, l'heure et le message du commit. L'en-tête de l'onglet indique quand le serveur a été déployé pour la dernière fois.

• Journal : chaque déploiement dispose d'un journal en direct, qui se met à jour pendant son exécution. Hide log le referme.
• Rollback en un clic : cliquez sur Deploy again sur un déploiement antérieur pour redéployer cet état une fois de plus.
• Annuler : les déploiements en attente ou planifiés peuvent être annulés.

Plusieurs serveurs peuvent déployer en même temps, mais chaque serveur n'exécute qu'un seul déploiement à la fois. Un nouveau déclencheur remplace un déploiement plus ancien encore en attente.

Statut dans votre dépôt

Lorsque Show deploys in the repository est activé, votre commit affiche un statut Daki Hosting / le nom de votre serveur : jaune pendant le déploiement, puis une coche verte ou une croix rouge, avec un lien vers l'onglet Git Deploy.

• Sur GitHub, un déploiement apparaît aussi sous Deployments, avec le nom de votre serveur comme environnement.
• Avec l'app GitHub, le statut est écrit par Daki Git Deploy et affiche son logo ; rien d'autre à configurer. Avec un token, il affiche l'image du compte auquel appartient le token, et le token a besoin des permissions d'écriture (voir Permissions du token).
• Vous pouvez le désactiver serveur par serveur. Seuls le statut et le lien sont publics — aucun journal ni détail d'erreur.

Équipes et permissions des sous-utilisateurs

Les sous-utilisateurs disposent de leur propre groupe de permissions Git Deploy :

Les sous-utilisateurs n'ont aucun accès à Git Deploy par défaut — c'est vous qui décidez qui obtient quelle permission. Le propriétaire du serveur peut toujours tout faire.

Sécurité

• Les tokens et secrets sont stockés chiffrés et ne sont jamais envoyés à votre navigateur.
• Avec l'app GitHub, aucun token de longue durée à vous n'est utilisé pour les déploiements : chaque déploiement utilise une clé à courte durée de vie (1 heure) qui n'atteint que le dépôt de votre serveur.
• Vos propres accès GitHub déterminent les dépôts que vous pouvez connecter. Personne ne peut faire venir sur son serveur les dépôts d'une autre personne.
• Les webhooks sont signés avec un secret propre à chaque serveur. Les envois avec un mauvais secret ou pour un autre dépôt sont rejetés.
• Seule la personne qui a enregistré le token peut modifier le dépôt, ainsi les sous-utilisateurs ne peuvent pas utiliser le token du propriétaire pour charger d'autres dépôts privés.
• Si vous changez le Git service ou l'URL du serveur, le token enregistré est supprimé automatiquement à l'enregistrement.
• Les chemins protégés ne sont jamais écrasés, et Remove files that were deleted from the repository ne supprime que ce qu'Git Deploy a écrit lui-même.
• Le statut public dans votre dépôt ne contient ni journal ni détail d'erreur.

Limites connues

• Un dépôt et un accès par serveur.
• Chaque serveur n'exécute qu'un déploiement à la fois.
• Le statut dans votre dépôt n'apparaît qu'une fois le déploiement réellement démarré, et non pendant l'attente de la CI.
• Les fichiers de release ne sont extraits que s'il s'agit de fichiers .zip ; un .tar.gz est téléversé comme fichier.
• Les dossiers vides restent en place après Remove files that were deleted from the repository.
• Les liens symboliques du dépôt ne sont pas déployés.
• GitLab n'a pas de pré-releases ; une release datée dans le futur compte comme pré-release.
• GitLab : les fichiers de release téléversés dans le projet (/uploads/…) ne peuvent pas être téléchargés avec un token depuis des projets privés ; les liens vers le registre de paquets fonctionnent.
• Connect with GitHub n'est disponible que pour GitHub ; GitLab, Gitea et Forgejo utilisent un token.

FAQ et dépannage

Étapes suivantes

• Subusers — Donnez accès à votre équipe et décidez qui peut déployer.
• Variables d'environnement — Gardez tokens et mots de passe hors de votre dépôt.
• Paramètres de démarrage — Définissez la commande de démarrage avec laquelle tourne votre code déployé.
• Sauvegardes — Enregistrez des sauvegardes automatiques de votre serveur sur Google Drive.