↓ Aller au contenu
Blog Marc JESTIN

Webhooks & CI/CD : Quand Dokploy et Gitea refusent de se parler

·453 mots·3 mins
Informatique Et Technologies Numériques Tutoriels Journal #Devops #Gitea #Dokploy #Ci-Cd #Webhook #Docker
Sommaire

Bonjour,

J’ai un peu galéré pour faire tourner mon flux de travail (workflow) pour automatiser les mises à jour automatiques de ce blog lorsque je publie (push) la branche main de mon dépôt sur mon serveur gitea.

Le défi : Automatiser le déploiement
#

L’objectif était simple : utiliser les Gitea Actions pour que chaque git push déclenche automatiquement la mise à jour du conteneur de mon site sur mon instance Dokploy.

Sur le papier, il suffit d’un simple curl pour appeler l’URL du Webhook fourni par Dokploy. En réalité, ce fut un véritable exercice de « débogage à l’aveugle ».

Symptômes : « Tous les indicateurs sont au vert, mais rien ne bouge »
#

Le premier diagnostic était déroutant :

  • Le suivi des Actions Gitea affichait un beau succès (Pastille verte).
  • L’interface de Dokploy, elle, restait désespérément muette : aucune trace de nouveau déploiement.

C’est ici qu’intervient la règle d’or du DevOps : Ne jamais faire confiance à un code de sortie 0 sans vérifier le corps de la réponse.

Le diagnostic : À la chasse au “Branch Not Match”
#

En passant le curl en mode verbeux et en capturant la réponse du serveur, le coupable a fini par se montrer : {"message":"Branch Not Match"}

Dokploy recevait bien l’appel, mais il le rejetait car il n’arrivait pas à identifier de quelle branche parlait le webhook. Le problème venait de plusieurs facteurs combinés :

  1. La redirection fantôme (301) : Mon instance étant derrière un reverse-proxy, l’URL HTTP était redirigée vers HTTPS. Sans l’option -L, curl s’arrêtait à la redirection sans transmettre les données.
  2. Le manque d’identité : Gitea n’envoie pas les mêmes en-têtes (headers) que GitHub. Dokploy, ne voyant pas l’étiquette familière, ignorait les paramètres de la requête.

La solution : Un appel « blindé »
#

Pour résoudre ce conflit de communication, il a fallu « forcer » la négociation entre le client et l’API de Dokploy en ajoutant des éléments cruciaux dans le workflow Gitea :

  • Le suivi de redirection (-L) : Pour suivre le passage du HTTP au HTTPS.
  • L’en-tête de contenu (Content-Type: application/json) : Pour confirmer le format des données.
  • L’en-tête d’événement (X-Gitea-Event: push) : Pour que Dokploy sache qu’il doit traiter l’appel comme une action Git.
  • Le corps de la requête (-d) : Pour spécifier explicitement la branche (main).

Le code final du workflow Gitea
#

Voici à quoi ressemble l’appel qui a finalement débloqué la situation dans mon .gitea/workflows/deploy.yaml :

1
2
3
4
5
6

- name: Trigger Dokploy Webhook
  run: |
    curl -L -X POST "${{ secrets.DOKPLOY_DEPLOY_WEB_HOOK }}" \
      -H "Content-Type: application/json" \
      -H "X-Gitea-Event: push" \
      -d '{"ref": "refs/heads/main"}'

Ce bogue (issue) est documenté ici : https://github.com/Dokploy/dokploy/issues/2149

Au plaisir,

Marc JESTIN
https://marcjestin.fr