Gitea nous convient pour le moment. Je l'ai choisi car il est très simple à configurer et simple à déployer, et nous n'avons pas beaucoup de test d'intégration qui justifierai autre chose (pour le moment).
Gitlab embarque son propre Postgres ... Il y a un fichier de configuration de 2300 lignes, contre 5 lignes pour Gitea.
on a minutieusement enchaîné les petites erreurs pour péter mon WE :
- Nous avons installé le paquet Gitlab de Debian sur une Debian Stretch sur ARM à l’origine. C'était un bon choix car ce package utilisait la version Debian de Postgres et était disponible sur ARM.
- Le serveur n'était pas très stable, aussi je n'aime pas l'ancienne interface de Gitlab, j'arrive jamais à retrouver ce que je cherche, et je trouve ça lent. Alors, je décide de migrer sur Gitea...
- Pour la migration, il fallait disposer de la version 4 de l'API de Gitlab. Donc on décide de mettre à jour notre Gitlab.
Et là, c'est le drame ...
- d'abord je le backup du serveur
- La mise à jour du paquet ne fonctionnant pas, je mets à jour la distribution. Tout ce passe nickel, sauf que Gitlab n'est toujours pas installable...
- Je remets encore à jour le serveur (vers SID), idem
- Je cherche à installer la version officielle, mais pas d'image pour l'architecture ARM.
En installant la version officiel sur un serveur x86-64, je constate la complexité délirante de ce produit : il faut 5 minutes au serveur pour "générer sa configuration"... Jamais je n'aurais installé Gitlab si j'avais assisté à ça. Ce n'est pas moi qui ai installé le serveur, et je comprends bien que les packageur officiel de Debian ont du se tirer une balle en essayant de packager cette bouse.
N'arrivant pas à importer la backup Postgres dans la version embedded de Postgres, je décide de remettre le backup. Et là, problème :
pour installer le backup, il faut créer une instance ARM (identique à celle d'où provient le backup), cool, sauf que Scaleway n'a plus d'instance ARM depuis un baille, et comme c'est installé dans la partition Root, je ne peux rien en faire.
Donc ce We, je vais me coltiner le modèle de Gitlab, l'API de Gitea, et faire l'importation de ce que je peux (utilisateur, clés, repos, organisation, tickets). Je fais ça en Groovy pour l'info. C'est pas compliqué, mais très chiant.
Au final, j'aime bien Debian et ARM. Il faut juste faire très attention lors du choix d'un logiciel, surtout aussi fondamental qu'une forge qui doit être pérenne, à la complexité de celui-ci.
Clairement Gitlab est trop complexe à intégrer. Puis j'aime vraiment pas avoir Postgres10.2 installé, alors que Debian propose déjà 3 versions de Postgres..
[^] # Re: Markdown
Posté par YBoy360 (site web personnel) . En réponse au journal Sorties de Micronaut 1.3.0 et Micronaut Data 1.0. Évalué à 2. Dernière modification le 07 février 2020 à 07:19.
Gitea nous convient pour le moment. Je l'ai choisi car il est très simple à configurer et simple à déployer, et nous n'avons pas beaucoup de test d'intégration qui justifierai autre chose (pour le moment).
Gitlab embarque son propre Postgres ... Il y a un fichier de configuration de 2300 lignes, contre 5 lignes pour Gitea.
on a minutieusement enchaîné les petites erreurs pour péter mon WE :
- Nous avons installé le paquet Gitlab de Debian sur une Debian Stretch sur ARM à l’origine. C'était un bon choix car ce package utilisait la version Debian de Postgres et était disponible sur ARM.
- Le serveur n'était pas très stable, aussi je n'aime pas l'ancienne interface de Gitlab, j'arrive jamais à retrouver ce que je cherche, et je trouve ça lent. Alors, je décide de migrer sur Gitea...
- Pour la migration, il fallait disposer de la version 4 de l'API de Gitlab. Donc on décide de mettre à jour notre Gitlab.
Et là, c'est le drame ...
- d'abord je le backup du serveur
- La mise à jour du paquet ne fonctionnant pas, je mets à jour la distribution. Tout ce passe nickel, sauf que Gitlab n'est toujours pas installable...
- Je remets encore à jour le serveur (vers SID), idem
- Je cherche à installer la version officielle, mais pas d'image pour l'architecture ARM.
En installant la version officiel sur un serveur x86-64, je constate la complexité délirante de ce produit : il faut 5 minutes au serveur pour "générer sa configuration"... Jamais je n'aurais installé Gitlab si j'avais assisté à ça. Ce n'est pas moi qui ai installé le serveur, et je comprends bien que les packageur officiel de Debian ont du se tirer une balle en essayant de packager cette bouse.
N'arrivant pas à importer la backup Postgres dans la version embedded de Postgres, je décide de remettre le backup. Et là, problème :
pour installer le backup, il faut créer une instance ARM (identique à celle d'où provient le backup), cool, sauf que Scaleway n'a plus d'instance ARM depuis un baille, et comme c'est installé dans la partition Root, je ne peux rien en faire.
Donc ce We, je vais me coltiner le modèle de Gitlab, l'API de Gitea, et faire l'importation de ce que je peux (utilisateur, clés, repos, organisation, tickets). Je fais ça en Groovy pour l'info. C'est pas compliqué, mais très chiant.
Au final, j'aime bien Debian et ARM. Il faut juste faire très attention lors du choix d'un logiciel, surtout aussi fondamental qu'une forge qui doit être pérenne, à la complexité de celui-ci.
Clairement Gitlab est trop complexe à intégrer. Puis j'aime vraiment pas avoir Postgres10.2 installé, alors que Debian propose déjà 3 versions de Postgres..