Migrer ses dépôts GitHub vers Gitea sur VPS

Dans l'interface Gitea, allez dans + → New Organization, choisissez un nom identique à votre organisation GitHub (cela simplifiera la mise à jour des remotes).

Ou via l'API :

curl -s -X POST https://git.votre-domaine.com/api/v1/orgs \
  -H "Authorization: token VOTRE_TOKEN_GITEA" \
  -H "Content-Type: application/json" \
  -d '{"username":"mon-org","visibility":"private"}'

Récupérez la liste de vos dépôts (paginée à 100 par page) :

curl -s -H "Authorization: token VOTRE_TOKEN_GITHUB" \
  "https://api.github.com/orgs/MON_ORG/repos?per_page=100&page=1" \
  | jq -r '.[].name' > repos.txt

L'endpoint GitHub utilisé ici est GET /repos/{owner}/{repo}/tarball/{ref} pour l'archive complète, et GET /orgs/{org}/repos pour l'inventaire. Vérifiez la documentation officielle à docs.github.com.

L'endpoint POST /api/v1/repos/migrate de l'API Gitea v1 accepte une URL de source GitHub (documentation officielle : gitea.io). Pour chaque dépôt :

while IFS= read -r REPO; do
  curl -s -X POST https://git.votre-domaine.com/api/v1/repos/migrate \
    -H "Authorization: token VOTRE_TOKEN_GITEA" \
    -H "Content-Type: application/json" \
    -d "{\n      \\\"clone_addr\\\": \\\"https://github.com/MON_ORG/$REPO\\\",\n      \\\"auth_token\\\": \\\"VOTRE_TOKEN_GITHUB\\\",\n      \\\"uid\\\": 2,\n      \\\"repo_name\\\": \\\"$REPO\\\",\n      \\\"issues\\\": true,\n      \\\"labels\\\": true,\n      \\\"milestones\\\": true,\n      \\\"mirror\\\": false\n    }"
done < repos.txt

uid est l'identifiant numérique de votre organisation Gitea (visible dans l'API GET /api/v1/orgs/mon-org). Le champ mirror: false indique un import ponctuel — passez à true si vous voulez une synchronisation continue pendant la phase de transition.

Pour chaque dépôt cloné sur votre poste :

git remote set-url origin https://git.votre-domaine.com/mon-org/mon-repo.git

Ou en SSH si vous avez ajouté votre clé publique dans Gitea (Settings → SSH / GPG Keys) :

git remote set-url origin [email protected]:mon-org/mon-repo.git

Vérifiez avec git remote -v puis testez un git fetch pour confirmer que le remote répond.

Dans Gitea, pour chaque dépôt : Settings → Webhooks → Add Webhook. Collez l'URL de votre CI ou de votre service tiers (Slack, Woodpecker CI, etc.) en remplaçant github.com par git.votre-domaine.com.

Les événements disponibles (push, pull_request, issues, release) sont identiques à ceux de GitHub — les payloads ont la même structure de base pour la majorité des intégrations.

Installez le runner officiel sur votre VPS :

wget -O gitea-runner https://dl.gitea.com/act_runner/latest/act_runner-latest-linux-amd64
chmod +x gitea-runner
./gitea-runner register --no-interactive \
  --instance https://git.votre-domaine.com \
  --token VOTRE_TOKEN_RUNNER \
  --name vps-runner \
  --labels ubuntu-latest:docker://node:20-bullseye
./gitea-runner daemon &

Le token de runner se génère dans Gitea : Site Administration → Runners → Create new Runner Token.

Vos fichiers .github/workflows/*.yml existants sont compris par gitea-runner sans modification pour les actions courantes (actions/checkout, actions/setup-node, etc.). Renommez le dossier .github/workflows/ en .gitea/workflows/ pour activer le runner Gitea de façon propre (les deux chemins sont supportés, mais .gitea/ est le chemin natif).

Symptôme : git clone [email protected]:… échoue avec Permission denied (publickey).

Vérification : dans Gitea, Settings → SSH / GPG Keys — la clé publique que vous utilisez doit y figurer. Ajoutez-la si elle est absente (cat ~/.ssh/id_ed25519.pub | pbcopy ou xclip).

Si la clé est présente mais l'erreur persiste, vérifiez que le port SSH de Gitea est bien 22 (ou le port configuré) : ssh -vT [email protected] -p 22 affichera la négociation et le message d'acceptation de Gitea si la clé est reconnue.

Symptôme : git fetch renvoie fatal: repository 'https://git.votre-domaine.com/…' not found.

Diagnostic : git remote -v — vérifiez que l'URL pointe bien vers votre instance Gitea et non vers github.com. Si l'URL est correcte, connectez-vous à l'interface Gitea et confirmez que le dépôt existe sous le bon nom d'organisation. Un POST /api/v1/repos/migrate qui a échoué en silence laisse le dépôt absent sans message d'erreur dans le remote local.

Symptôme : un git push ne déclenche pas de build dans votre CI.

Diagnostic : dans Gitea, Site Administration → System Settings → Git Hooks — activez la journalisation des hooks. Puis, dans le dépôt, Settings → Webhooks → dernière livraison : le champ « Response » affiche le code HTTP renvoyé par votre CI. Un 404 signifie que l'URL du webhook pointe vers une route inexistante ; un 401 signifie un secret HMAC mal configuré.

Activez le mode debug du runner : dans le fichier de configuration de gitea-runner, passez log_level à debug et relancez le daemon. Les logs afficheront la réception de chaque événement et le code d'activation du job.