ecloudserv docs

Déploiement Git

Relier un dépôt à un conteneur, et mettre en ligne d'un bouton — ou à chaque poussée.

Un projet associe un dépôt Git, une branche et un conteneur. Chaque mise en ligne récupère le code, l'installe, le construit, puis redémarre le service. Tout est journalisé, et chaque version reste redéployable.

Créer un projet#

1

Ouvrir Projets → Nouveau projet

Renseigne le dépôt au format proprietaire/depot (ou colle son URL GitHub) et la branche à suivre.

2

Choisir le conteneur cible

C'est là que le code sera déployé. Tu peux laisser le champ vide et rattacher le conteneur plus tard, mais aucune mise en ligne n'est possible tant qu'il manque.

3

Renseigner les commandes

L'installation et la construction sont exécutées dans le conteneur. Laisser un champ vide saute simplement l'étape.

Le dépôt et la branche sont vérifiés tout de suite

Beaucoup de dépôts sont sur master et pas main. La vérification a lieu à la création plutôt qu'à la première mise en ligne : découvrir l'erreur à ce moment-là serait le pire moment pour l'apprendre.

Ce que fait une mise en ligne#

ÉtapeCe qui se passe
RécupérationL'archive de la branche est téléchargée puis écrite dans le conteneur.
Mise en placeLe dossier extrait par GitHub est remonté à la racine (ou dans la racine du projet), fichier par fichier.
ConstructionLes commandes d'installation puis de construction sont exécutées, dans l'ordre.
RedémarrageLe conteneur est redémarré pour prendre le nouveau code.

La commande de démarrage n'est pas appliquée automatiquement

Elle dépend de l'image du conteneur, dont les noms de variables changent d'une image à l'autre : l'écrire au hasard casserait des conteneurs qui fonctionnent. Le projet la mémorise et le journal la rappelle, mais c'est l'onglet Démarrage du conteneur qui l'applique.

Suivre et relire#

La page de détail d'un projet liste les mises en ligne avec leur état, leur durée et le commit concerné. Le journal se remplit en direct pendant l'opération.

  • Redéployer une version : rejoue la même branche depuis le déploiement choisi, avec un journal neuf.
  • Annuler : libère le verrou « un déploiement à la fois ». Une commande déjà lancée dans le conteneur, elle, continue — le journal le dit.

Déploiement automatique#

Active Déploiement automatique dans les réglages du projet, puis va dans l'onglet Webhook : il donne l'URL et le secret à coller dans GitHub (Settings → Webhooks → Add webhook), avec le type de contenu application/json et l'évènement push.

ce que GitHub envoie
POST /deploy/hook/<id-du-projet> X-Hub-Signature-256: sha256=... Content-Type: application/json

La signature est vérifiée en temps constant, et seules les poussées sur la branche suivie déclenchent une mise en ligne : une poussée sur une autre branche répond « ignorée » plutôt que d'être silencieusement perdue.

Dépôts privés

La récupération se fait sans jeton d'accès : seuls les dépôts publics sont pris en charge pour l'instant.

Les commandes de build ont besoin de l'agent

Elles sont exécutées par l'agent du node (docker exec), ce qui suppose un conteneur démarré et un agent à jour. Quand ce n'est pas le cas, le journal le signale — l'étape n'est jamais présentée comme réussie.

Voir aussi Variables & secrets pour la configuration, et Mise à l'échelle pour dimensionner le conteneur.