Git, auto-push lors d'un commit

Bonsoir,

J’aurais aimé savoir s’il était possible de mettre automatiquement à jour un repo git lorsque qu’il y a eu un commit dessus (commit directement sur la branche master, ou un merge).

Car je code un site web, et j’aimerais bien que le serveur dev.domaine.com ce mettent à jour directement lorsque qu’il y a un commit.

Est-ce faisable ?
(Si ça à une importance, je travaille sur la version online de Gitlab).

Salut,

Un cron régulier qui fait un git pull ? Après, c’est un peu risqué je trouve, au cas où tu fais une erreur dans ton commit, que tu remarques après.

Oui, mais c’est uniquement pour un environnement de dev

Je ne me permettrais pas de faire cela sur de la Prod. C’est juste que j’ai l’habitude de travailler en local, mais pour mon histoire de socket (Je me suis finalement penché sur Flask), ça ne marche pas très bien de tout avoir en local.

Edit: Et pour le Cron, en effet ça doit marcher. Mais ça ne me parait pas très propre. J’ai vu qu’il y avait la possibilité de paramétrer des push sur Gitlab, ça fonctionne comment ?

Salut,

Si tu veux absolument faire ça (même si c’est probablement la pire idée que tu puisses avoir), pourquoi tu n’écris pas un post-commit hook qui fait un push ?

Je suis curieux : pourquoi est-ce que les websockets ne fonctionnent pas très bien en local ?

Et bien en fait je ne sais pas trop, tout d’un coup wamp à commencer à déconner et m’envoyer des 404 lorsque le serveur flask était lancée.

C’est quoi le rapport avec WAMP ? À part un conflit de port, je vois pas trop.

Moi non plus je ne vois pas, je vais essayé d’investiguer. Peut être un soucis de virtualhost

Bonsoir,

J’ai l’impression que tu mélanges deux choses :

• Le fait d’avoir deux commandes distinctes commit et push ;
• Et celui de devoir télécharger les nouveaux commits sur les clones du dépôt.

Que souhaites-tu réellement faire ?

Alias bash au pire.

Par contre c’est very very bad practice… Tu perds un peu tout l’intérêt de git en faisant ça.

Edit : pardon j’avais mal compris la question. En fait c’est plutôt un pull que tu veux automatiser ? Pour mettre en prod automatiquement tes commits dès qu’ils sont poussés, c’est ça ? Dans ce cas t’as qu’à faire un cron effectivement..

Effectivement je me suis mal exprimé, ce n’est non pas à chaque commit mais à chaque push.

Oui mais je ne développe pas sur mon serveur qui distribue les pages Web… ou alors j’ai pas compris ta phrase

Et autrement ce que je peux faire, c’est créer une page web annexe avec un bouton permettant de faire un pull.

Je perd un petit peu d’automatisation, mais pas forcément beaucoup de temps et c’est probablement plus propre qu’un cron..

Git est complètement décentralisé, il est aberrant de demander à un serveur A distant de puller à chaque push que tu pourrais faire sur un autre serveur B lorsque tu peux soit pusher directement sur A, soit mettre un hook sur B pour pusher sur A.

Je comprend mieux. J’étais dans l’optique que mon serveur Gitlab était le serveur de référence.
Donc si j’ajoute mon serveur secondaire dans les remotes et que je fais un git push --all master ça va push sur les deux ?
Et si un autre utilisateur fait un push sur le serveur Gitlab, que je fais un pull sur mon PC, et que je push sur le serveur web, la version sera à jour avec le serveur Gitlab ? (D’après ce que j’ai compris Oui, sinon j’ai loupé un point).

Je vous remercie de ces informations complémentaires.

git push --all va pusher tous les commits/tags/etc qu’il va trouver dans les branches locales sur le remote par défaut. Pour pusher vers ton remote, il faut spécifier son nom à git push.

À part ça, tu as compris.

Donc je suis obliger de faire deux push ?

1
2

git push serverA master
git push serverB master

Oui, et c’est parfaitement logique. Si quelqu’un a pushé quelque chose sur serverA, il faudra bien résoudre les éventuels conflits avant de pusher le tout vers serverB.

Uniquement pusher ne met pas le code en prod.

Il faut encore détecter et réagir à l’événement côté serveur.