Pense bête personnel sur le travail à faire suite à la sortie de la 1.6.15

Pour information, j’ai également modifié la version anglaise de la documentation. Je ne sais pas, @cgeek, si tu peux également intégrer cette modification ?

C’est pour quoi cette image Docker ?

Car tu as déjà réalisé plein de contributions, mais je crois qu’il manque toujours celle pour laquelle tu as écrit ton premier message sur ce forum : l’installation via Docker ! :slight_smile:

Et bien oui, c’est bien celle-là ! :lol:

1 Like

C’est bon pour la version anglaise, je l’avais loupée !

1 Like

Je suis en train de travailler sur le Gitlab et le Gitlab-ci. Je pense que cela a généré une surcharge de travail qui fait que les outils montrent quelques signes de faiblesse.

Je voulais supprimer les pipelines de mon projet de test pour libérer un peu d’espace (supprimer les artifacts générés), mais je pense que je n’ai pas les droits. @cgeek, @elois, pouvez-vous faire un peu de ménage ?

Oui c’est parce que j’étais dessus en même temps du coup c’est lent c’est normal :wink:

je vois que tu les a mis en temporaire donc elles disparaitrons toutes seules, je viens de vérifier la partition est a 6% ont est large :wink:

Voilà, j’ai terminé ce que je voulais faire pour la publication des versions. Pour vous le présenter, j’ai fait une petite vidéo (moins de 10 minutes) :

Notez que j’ai corrigé le problème pour la conservation des artefacts (le « keep » est maintenant automatique lorsque l’on publie la version). Notez aussi que lorsque je parle de Duniter qui génère les archives source à la volée, je voulais bien entendu parler de Gitlab !

@cgeek, @elois, qu’en pensez-vous ? Il y a une MR qui contient tout ça dans le projet.

3 Likes

Merci beaucoup @sveyret c’est génial !!! :grinning::rofl:

Si je comprend bien les pré-releases ne sont pas publiez sur le wiki, seulement les releases stable c’est ça ?

Du coup avec un système on peut donner le lien vers le wiki aux non-testeurs et ont aura une séparation claire entre test et production, c’est vraiment chouette :slight_smile:

EDIT : @sveyret juste un détail par rapport au ficher yarn.lock, il ne faut pas le mettre dans le gitignore on en a besoin ! C’est la présence de ce fichier qui permet de nous assurer cgeek et moi que l’on a exactement les mêmes versions de chaque dépendances sur nos environnements de dev !

1 Like

Oui, c’est bien ça…

D’ac, je modifierai la MR dans la soirée.

C’est fait :wink:

Ah oui, mais non… Cette opération était isolée dans un commit séparé, donc il suffit de le supprimer ! Maintenant, c’est fait… :stuck_out_tongue:

Désolé, j’ai dû partir un peu rapidement tout à l’heure, mais en fait, je n’ai pas trop compris. Le yarn.lock, il est bien régénéré à chaque fois qu’on exécute la commande yarn. Du coup, en quoi est-ce qu’il est important ?

J’ai une autre question technique : lorsqu’on compile le programme avec la commande yarn, en fait, c’est surtout de la transpilation qui se fait, transformant le typescript en javascript. Donc théoriquement, la compilation pourrait être faite une seule fois pour tous les systèmes, non ? Sauf qu’il y a aussi des dépendances, et que celles-ci sont parfois en binaire, donc dépendent du système… Du coup, on est bien obligé de compiler différemment sur chaque architecture/système. Je me trompe ?

Et bien justement, il n’est régénéré que quand on exécute la commande yarn, ce que l’on fait très peu au final, le plus souvent quand on code on se contante de transpiler avec la commande yarn tsc et donc quand on exécute pour tester notre code tout frais c’est bien le yarn.lock du dépôt qui fait foi

Oui voila yarn fait bien plus que de la transpilation en fait, il installe toute les dépendances, et ont a des dépendances en c++ notamment, donc oui il faut compiler différemment sur chaque architecture/système !

1 Like

Merci ! :slight_smile:

Du coup, je vous laisse mon fork encore quelques jours, si vous voulez tester un peu avant de fusionner la MR (n’hésitez pas, je n’y travaillerai plus pour le moment). Je le supprimerai plus tard.

1 Like

Ça, c’est fait…

Image Docker : ça avance.

Je ne peux pas utiliser MisybaG parce que je suis obligé de mettre le USE flag -bindist. Pour ceux qui ne connaissent pas, cela veut dire que le binaire généré ne peut pas être distribué en tant que tel pour des problèmes de droit.

J’ai par contre réussi à contourner le problème que j’avais sur Alpine Linux (la dernière version de sqlite3 corrige l’incident). J’ai une image fonctionnelle qui pèse 264Mio.

Pour aller plus loin, il me faudrait un nouveau projet docker/duniter/duniter sous Gitlab.

De même, j’aimerai savoir comment vous envisagez l’image :

  • brute, ou avec un peu de configuration (j’ai fait une version serveur avec interface web) ?
  • faut-il pouvoir spécifier facilement un fichier de clés ?
  • la base de données doit-elle être sur la machine hôte ?
1 Like

@sveyret je viens de te créer un dépot docker/duniter/duniter-ts, car comme on a maintenant un projets de 2ème implémentation de duniter se serait bien qu’on commence a en tenir compte dans les nouveaux noms :wink:

Je t’ai donner les droits developer, mais si tu a besoin d’être master du dépôt ça ne me pose pas de problème :slight_smile:
C’est un repo moins critique que le release-builder

Si on peut avoir une version configurable permettant d’avoir l’interface web c’est carrément mieux :slight_smile:

De préférence oui, mais ce n’est pas une priorité absolue.

Si tu la stocke en dehors du conteneur je ne vois pas trop l’intérêt de dockerisé, la bdd sqlite est accédée constamment donc niveau perf c’est sans doute mieux qu’elle soit dans le même conteneur que duniter.

1 Like

Merci, je pense que développeur suffira.

@elois, est-ce que tu pourrais faire un commit d’un README ? Je crois que la branche master doit exister pour que je puisse envoyer quelque chose.

Pas d’urgence, je vais couper l’ordinateur maintenant, je travaillerai dessus demain.

Bonne soirée.