Build des releases duniter dans Docker

Par contre, il faudra soit mettre le tag 17.12.1, soit modifier le script build.sh pour lui dire de prendre le tag 0.0.6 pour utiliser cette image pour générer Duniter.

Par rapport au runner, je pense que le plus simple est que je revois la procédure de livraison pour qu’elle s’adapte aux deux cas. Par contre, @elois, peux-tu m’indiquer ce qu’il y a à faire pour déployer les livrables ?

C’est fait, note qu’il s’agit du tag v0.0.6 :wink:

Alors jusque la on les déployais sur le github, comme expliqué ici : https://duniter.org/fr/wiki/duniter/livraisons/
Ce serait bien qu’on les upload directement sur notre gitlab maintenant mais je ne sais pas du tout comment ça marche, @florck peut tu nous aider ?

1 Like

Je peux répondre un peu à sa place, car il avait déjà fait des tests pour nous : https://git.duniter.org/florck/demo-runner-perso/blob/master/.gitlab-ci.yml

Dans les jobs de build, certaines commandes créent des fichiers livrables (test_windows.txt, test_linux.txt dans la partie scripts) et d’autres (ce qui se trouve sous artifacts je pense) permettent de les conserver sur GitLab aux côtés du tag.

Par exemple on a les livrables ici : https://git.duniter.org/florck/demo-runner-perso/tags/test20

2 Likes

J’ai fais un gros travail de ré-écriture afin que l’image Docker puisse servir à la fois au script de génération manuel et au gitlab-ci. J’ai déjà fait les MR à la fois sur l’image Docker et sur Duniter, mais il me reste encore quelques tests à faire avec gitlab, et pour cela, il me faudra modifier .gitlab-ci.yml, ce qui n’est pas encore fait.
Tout ça donc pour vous dire que vous pouvez dores-et-déjà faire des tests si vous le souhaitez, mais ce serait bien que vous attendiez encore quelques jours avant de valider les MR.
Merci ! :slight_smile:

1 Like

@sveyret merci beaucoup, en tout cas le build de l’image Docker se passe bien : https://git.duniter.org/docker/duniter/release-builder/-/jobs/1085

La priorité c’est de pusher la nouvelle image Docker, donc dit moi quand tu pense que je peut le faire :wink:

Si tu a besoin de faire des tests qui nécessitent plus de droits, n’hésite pas a me solliciter :slight_smile:

EDIT : j’ai bien repéré qu’il faudra que je publie l’image builder en v1.0.0 :wink:

1 Like

Question : Pourquoi produire Duniter dans un conteneur Docker plutôt que dans une VM ? Quel intérêt ? Est-ce qu’il n’y a pas un risque d’incompatibilité ensuite à exécuter le build Duniter en dehors du conteneur docker ?

Bonjour @Inso, le premier intérêt est que Docker est plus léger qu’une VM. L’ancien mode, avec Vagrant, ne fonctionnait pas partout (ça ne marchait pas sur mon Gentoo, par exemple) ; ce n’est pas le cas avec Docker.
Le second intérêt est qu’on peut utiliser la même procédure pour générer et diffuser automatiquement les livrables avec gitlab-ci. C’est le sujet sur lequel je suis en train de travailler.
Pour les risques d’incompatibilité, je ne comprends pas ta question. On ne peut pas plus (ni moins) exécuter le script en dehors de Docker qu’on ne pouvait l’exécuter en dehors de Vagrant

1 Like

C’est surtout le livrable final. Quand on build une release dans une VM, les binaires sont construits suivant les versions des librairies présentes sur la VM. Dans le cadre de docker, est-ce que ces livrables seront compatibles quand ils seront exécutés dans des contexte non dockerisés, sur une couche OS standards ?

Oui, bien sûr. Bien sûr, j’ai encore quelques tests à faire pour m’assurer que tout va bien, mais cela ne devrait pas poser de problème.
De la même façon que pour une VM, les binaires sont construits avec les bibliothèques présentes sur l’image Docker utilisée. Avec Docker, en gros, seul le noyau Linux est partagé, pour le reste, ça fonctionne (presque) comme une VM.

1 Like

Oui, mais il me semble que les images docker ne contiennent pas nécessairement les même librairies que les OS, c’est pour ça que je me pose la question :slight_smile:

Dans ce cas, c’est une image basée sur une Ubuntu 16.04… On devrait bien avoir les mêmes. :slight_smile:

@elois, c’est bon pour l’image Docker, tu peux déployer… :slight_smile:

Par contre, suite à mes tests, j’ai encore quelques modifications à apporter sur la branche de Duniter. Il va falloir attendre encore un peu pour faire vos tests.

1 Like

La partie Duniter est également prête. J’ai besoin de faire encore quelques tests par rapport aux fichiers générés.

Attention, pour tester, il va falloir d’abord déployer l’image Docker puis créer un gitlab-ci runner avec les tags nodejs et nwjs. D’ailleurs, gitlab est actuellement en attente de ce runner.

J’ai modifié le .gitlab-ci.yml pour qu’il génère automatiquement un livrable à chaque nouveau commit. Pour tout ce qui n’est pas un tag, les livrables seront conservés par gitlab pendant 8 heures. Dans le cas contraire, la conservation est sans limite (il faudra vérifier le paramétrage de gitlab qui peut définir une limite quand même).

1 Like

ok je fait ça maitenant :wink:

1 Like

Par pure curiosité, ça vient d’où, ce redshift ?

C’est le petit nom de notre serveur dédié a la CI :slight_smile:

1 Like

J’ai installer le .deb version server sur ma machine et il ne semble pas fonctionner :

$ duniter start
module.js:664
  return process.dlopen(module, path._makeLong(filename));
                 ^

Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /opt/duniter/node_modules/sqlite3/lib/binding/node-v57-linux-x64/node_sqlite3.node)
    at Object.Module._extensions..node (module.js:664:18)
    at Module.load (module.js:554:32)
    at tryModuleLoad (module.js:497:12)
    at Function.Module._load (module.js:489:3)
    at Module.require (module.js:579:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/opt/duniter/node_modules/sqlite3/lib/sqlite3.js:4:15)
    at Module._compile (module.js:635:30)
    at Object.Module._extensions..js (module.js:646:10)
    at Module.load (module.js:554:32)

Par contre ces tag sont déjà pris, donc c’est génant, j’ai déployer le runner avec le tag redshift-duniter-builder, je vais modifier la config gitlab-ci en conséquence :wink:

1 Like

Comme quoi @Inso avait raison de se méfier.

Je vais regarder ça ce soir.

2 Likes