RĂ©installation complĂšte du service git de la plateforme.
Mise Ă jour du systĂšme sur la plateforme git
LâĂ©tĂ© dernier, suite Ă un gros plantage du serveur gitlab, lâensemble des dĂ©pĂŽts ont Ă©tĂ© migrĂ©s sous gitea.
gitea propose toutes les fonctionnalitĂ©s attendues dâun serveur git, et est bien adaptĂ© Ă un serveur de taille moyenne.
à ce jour le service héberge :
- 12 utilisateurs,
- 43 organisations ou groupe de dépÎts,
- 466 dépÎts,
- pour environs 4 Go de données.
La migration vers gitea 1.18 a montrĂ©e que lâinstallation initiale nâĂ©tait pas optimum. Elle sâĂ©tait faite dans lâurgence avec des scripts « Quick and dirty » pour convertir les sauvegardes gitlab a un format acceptable pour gitea.
De plus la sauvegarde native avec une base de donnĂ©e PostGres gĂ©nĂšre des problĂšmes lors de la restauration. AprĂšs avoir identifiĂ© ce problĂšme, une solution maison a Ă©tĂ© mise en place pour la sauvegarde et la restauration, cependant lâorganisation des rĂ©pertoires choisis initialement rendait la procĂ©dure de sauvegarde assez lente. Cette rĂ©installation complĂšte permettra de solutionner ce point.
Un dernier souci sur le service gitea apparaĂźt en particulier lors des « Pull Requests », cela est liĂ© Ă un problĂšme de timeout qui reste Ă corriger. Ce souci nâest pas bloquant puisquâil suffit dâattendre quelques secondes pour continuer la « Pull Request ».
Mise en place de « jobs » sur les dépÎts.
Pour lâinstant aucune solution simple nâa Ă©tĂ© trouvĂ©e pour mettre en place des procĂ©dures dâintĂ©gration continue.
Les deux principales pistes sont :
-
Jenkins qui Ă lâavantage pour moi dâĂȘtre un outil que je maĂźtrise mais qui est assez lourd et peu compatible avec les objectifs de garder une plateforme « basse consommation ».
-
Drone est sans doute la meilleure option, mais cela nĂ©cessite de dĂ©ployer docker sur la plateforme. Ce prĂ©requis nâest pas encore disponible.
Liens
኿