Retour d'expérience sur les mises à jour Gitea

Bonjour,

TL;DR: ça s’est passé comment la dernière fois que vous avez eu un soucis de mise à jour Gitea?

Évidemment si tout s’est magnifiquement passé et que vous n’avez eu aucun soucis, il y a peu a dire :grin: Mais c’est aussi intéressant. Si vous avez rencontré des problèmes (par exemple ceux qui sont apparus récemment ou même de plus anciens), c’est encore mieux.

Le contexte dans lequel je pose la question est le collectif Hostea, un CHATONS en gestation qui proposera de l’hébergement d’instances Gitea fédérées en assemblant un puzzle durable fait de transparence radicale, d’infrastructure as code histoire que les méthodes de déploiement du CHATONS soient, elles aussi, logiciel libre et de contributions (argent & code) aux projets sur lequel il s’appuie (Gitea bien sur, mais les autres aussi).

A++

2 « J'aime »

Bonjour Loïc,

Petit retour d’expérience de notre part puisque notre Gitea est en place chez nous depuis septembre 2019, et nous le mettons à jour à chaque nouvelle version. Nous utilisons PostgreSQL 14 pour la base de données.

Nous utilisons Gitea dans Docker. Depuis trois mois, nous utilisons la version rootless et nous stockons toutes les données de Gitea sur une share NFS. Voilà notre docker-compose.

De notre côté, nous n’avons que très rarement constaté de problèmes (peut être une ou deux fois en trois ans). On a tendance à s’exposer à beaucoup plus instabilités que d’autres infrastructures puisque nous mettons à jour nos services dès qu’une nouvelle mise à jour est disponible (en général, une semaine après).

Peut-être qu’une politique plus raisonnable consisterait à mettre à jour les logiciels seulement un mois après leur publication. Les accidents de mise à jour auxquels je pense auraient sans doute pu être évités avec une telle politique, car l’équipe de Gitea a tendance à publier rapidement des correctifs en cas de problème.

Concernant les problèmes dont il est question : je n’ai plus les détails en tête, cela fait un long moment que ce n’est pas arrivé, mais il me semble qu’il y avait un bug majeur qui a rapidement été réglé, mais qui a mis du temps (plusieurs jours) avant d’être publié dans une nouvelle version. Dans ce cas précis, j’ai le souvenir d’avoir utilisé une version de développement pour pallier temporairement à ce problème.

Il me semble qu’on a eu un autre problème sur une version mineure et que nous avons simplement rétrogradé la version de Gitea pour nous en sortir (avec les migrations, c’est un coup de bol je suppose, je n’aurais pas tenté cela sur une mise à jour vers une version majeure).

Les autres problèmes mineurs que nous avons rencontré étaient de notre faute : nous utilisons un thème personnalisé pour Gitea, et nous n’avons pas systématiquement vérifié les changements majeurs dans le CSS de Gitea pour mettre à jour notre thème. Généralement, cette situation nous conduisait à un hotfix de notre thème, sans plus. Deuxième erreur de notre faute : nous avons modifié certains templates de pages sans vérifier leur compatibilité à chaque nouvelle mise à jour.

Nous n’avons jamais eu de problème de migration ou de base de données avec Gitea à ma connaissance, alors que nous mettons à jour PostgreSQL à chaque version majeure (et mineure, évidemment). Nous avons probablement esquivé les bugs récents.

~ Neil

2 « J'aime »

Un grand merci pour ce retour d’expérience très détaillé :+1: Il corrobore utilement ce que j’ai aussi pu observer. Deux conseils qui pourraient vous être utiles:

  • En général aucune migration de base de donnée n’est ajoutée aux version stables, ce qui permet de revenir en arrière, par exemple de 1.15.11 à 1.15.10. Avec une exception notable sur les version 1.16.0, 1.16.1 et 16.2 en raison de régressions concernant les données associées à 2FA. Avant de revenir en arrière il faut:

    Si c’est identique tu peux revenir en arrière, sinon tu risque de casser durablement des « trucs » :fearful: C’est pas une méthode de vérification très pratique, il faut avouer, et il faudrait que gitea doctor puisse aider. J’aimerais bien implémenter quelque chose comme ça.

  • Comme vous utilisez un volume NFS, vous auriez pue être exposés à ce bug non encore élucidé. Mais comme vous êtes vraisemblablement en 1.16.8 sur https://git.42l.fr/, vous semblez immunisés. :magic_wand:

Comme je viens de terminer une première version du guide d’upgrade, je suis curieux de savoir:

  • Comment vous faites vos sauvegardes et quels commentaires vous auriez éventuellement sur la section correspondante du guide ?
  • Si vous utilisez gitea doctor pour vérifier que tout va bien.
  • Si vous flushez les queues avant de faire l’upgrade (elles contiennent des données structurées pour lesquelles il n’y a pas de process de migration, donc il faut les vider pour éviter que ça bug, en gros).
1 « J'aime »

Pour référence, un début de discussion au sujet de https://garagehq.deuxfleurs.fr/

Je me souviens qu’on a migré en faisant un export/import depuis le logiciel et que ça a cassé notre intégration avec Drone, ça nous a pris plusieurs jours à remettre ça en place.

Merci pour tes conseils :slight_smile:

Nous utilisons Borg Backup pour sauvegarder les données de tous nos services vers une machine off-site (chez Picasoft !), toutes les trois heures.
Nous n’exécutons aucune commande propre à Gitea avant ou après ce processus.

Quant à la BDD Postgresql, nous la répliquons sur notre serveur de stockage (réplication WAL) puis nous la sauvegardons avec Borg Backup de la même manière.

Je crois qu’on a dû utiliser la commande une fois, mais très rarement concrètement. Je viens de tester gitea doctor --all et gitea doctor --all --fix, il semble avoir trouvé quelques détails qu’il a réglés tout seuls, pratique !

On n’a jamais utilisé cette commande :flushed: je vais tâcher de prendre l’habitude.

1 « J'aime »

Cela pose des problèmes mais comme ça nous entraînerait un peu loin j’ai ouvert un sujet sur le forum Hostea ou nous pouvons continuer la discussion.