Je ne sais pas si quelqu’un a la possibilité de mettre ça en place, mais ça serait bien d’avoir un système de génération continue, c’est-à-dire qui compile et génère les paquets dès qu’on ajoute quelque chose sur une branche du git. Cela permettrait à ceux qui n’ont pas les distributions choisies de tester ce qu’ils font.
Si tu veut nous aider pour ça il suffit de créer un dépot duniter-build qui contient l’image docker qui vas bien puis de réécrire les script de build pour qu’ils utilisent cette image. Ensuite on n’a plus qu’a créer le runner associé sur notre serveur CI puis a configurer le .gitlab-ci.yml pour tenter une build a chaque tag par exemple 
les dépôts d’images docker sont ici : docker · GitLab
1 Like
Je vais essayer de m’en occuper, mais il n’est pas dit que j’ai le temps nécessaire pour cela. 
1 Like
Oui je comprend on manque tous de ce précieux temps, merci beaucoup pour tes contributions, fait ce que tu peut 
2 Likes
J’ai commencé… Mais là, je m’arrache les cheveux. Il y a des choses qui ne fonctionnent pas et je ne sais pas pourquoi.
Tout d’abord, le npm prune --production fait tellement bien le ménage qu’il ne reste plus assez d’information dans les répertoires pour ensuite exécuter node-pre-gyp --runtime=node-webkit --target=$NW_VERSION configure (le fichier package.json n’est plus présent dans le répertoire wotb, par exemple).
Ensuite, je n’ai pas trouvé qui installait le répertoire .nw-gyp qu’il faut patcher (avec 0.24.4_common.gypi). Chez moi, ce répertoire n’existe pas.
Si quelqu’un a une piste, je suis preneur !
Merci.
@Melua, j’ai corrigé le script. J’en ai profité pour ajouter une option DUNITER_SSD_OPTIONS qui te permettra de rajouter DUNITER_SSD_OPTIONS="--chdir \"/opt/duniter\"" dans le fichier duniter.conf.
@elois, as-tu une idée de la provenance des 2 problèmes que je rencontre ? Le problème avec le npm prune et le problème du répertoire .nw-gyp ?
Merci.
Merci, je vais rebaser mes modifications sur la nouvelle version de la branche 1.6. Je n’avais effectivement pas ces modifications.
Je suppose que cela corrige le problème lié au npm prune, mais est-ce que tu as une idée par rapport au répertoire .nw-gyp qu’il faut apparament patcher, mais que je n’ai pas sur mon système ? Quelle est la commande qui installe ce répertoire ?
Normalement c’est cette ligne là (1) :
node-pre-gyp --runtime=node-webkit --target=$NW_VERSION configure
Mais c’est curieux en effet, car dans le script je ne l’appelle pas avant d’effectuer ce patch (2) :
cp /vagrant/0.24.4_common.gypi ~/.nw-gyp/0.24.4/common.gypi
A mon avis si je supprime la VM et que je relance le build, il devrait échouer 
. Il faudrait que je fasse un appel à (1) avant (2), puis redérouler (1) et sa suite qui alors fonctionnera correctement. Bref bonne remarque @sveyret, le script semble buggué pour un nouvel utilisateur qui tenterait d’effectuer le build.
Je ne peux pas essayer moi-même avant plusieurs jours. Je me note ça dans un coin.
1 Like
Merci @cgeek, je ferai éventuellement des essais de mon côté. Je te tiens au courant si je trouve quelque chose.
@cgeek, effectivement, j’ai été obligé d’exécuter les commandes comme tu l’as signalé pour que cela fonctionne.
@elois, je pense avoir terminé avec la fabrication sous Docker. J’ai créé une MR associée à mes modifications. J’ai fait quelques tests chez moi qui se sont avérés concluants, mais si quelqu’un a l’occasion de confirmer, qu’il n’hésite pas.
J’en ai profité pour factoriser une partie du script de génération (j’ai utilisé des fonctions que j’ai déjà développées pour créer les paquets Gentoo). Si d’autres modifications ont eu lieu en parallèle dans build_deb.sh, cela va en compliquer les fusions, mais devrait améliorer la maintenance par la suite.
Pour utiliser Docker, j’ai dû créer une image basée sur Ubuntu contenant les outils nécessaires à la génération de Duniter. Pour le moment, le Dockerfile associé est sur mon GitHub (https://github.com/sveyret/docker-images/tree/master/duniter/ubuntu-build). Je pense que le mieux serait de la rapatrier sur le git de Duniter. J’ai bien vu le groupe Docker, mais je ne pense pas avoir les droits pour y créer un nouveau dépôt.
De même, pour faciliter la tâche à ceux qui ne veulent pas reconstruire l’image, je l’ai téléchargée sur Docker Hub. J’y ai créé pour cela une « organisation » Duniter. Je suis pour l’instant le seul a pouvoir y écrire, mais si vous, @cgeek ou @elois, avez un compte sur Docker Hub, je vous ajouterai comme propriétaire de l’organisation. Ce serait d’ailleurs une bonne chose afin que s’il m’arrive quelque chose, quelqu’un puisse toujours accéder à cette organisation.
1 Like
@sveyret je t’ai nommé master du groupe docker tu peut y créer un dépôt duniter-ts-build, ensuite tu peut t’inspirer de la config gitlab-ci des autres images docker pour le déploiement automatique sur notre registry : .gitlab-ci.yml · master · docker / dunitrust / dunitrust-rs-ci · GitLab
Une fois que le tes de build de l’image réussi tu peut pusher un tag et ça déploiera automatiquement sur notre registry. De la je peut créer un runner sur notre serveur CI/CD qui utilisera ton image docker avec un tag du style duniter-ts-build et j’activerai ce runner pour le dépot duniter, nous pourrons alors tester tout ça
Merci beaucoup 
Je viens de créer un compte duniterteam, par contre il n’est pas encore activé, dés qu’il le sera tu pourra l’ajouter comme owner
EDIT : @sveyret c’est bon il est activé
1 Like
Super boulot, c’est propre ! Et tu fais bien de proposer des modifications, car le script Vagrant était assez illisible 
Je viens de créer le dépôt docker/duniter-release sur tes conseils. Tu peux y effectuer une MR avec le Dockerfile que tu as développé, puis j’y créerai un tag afin que l’image soit déployée.
À terme tu pourrais être mainteneur sur ce dépôt, pour l’instant je te demande d’accepter la simple contribution car bien sûr il s’agit d’un dépôt critique en termes de sécurité, or pour le moment je ne te connais pratiquement pas.
Voilà, j’essaierai de réaliser un build avec cette image ensuite, et si c’est bon eh bien … ça deviendra l’outil de build officiel pour nos futures releases (dès la 1.6).
2 Likes
@cgeek a déjà préparé le terrain !
C’est fait… J’ai modifié légèrement le Dockerfile que j’avais créé à l’origine pour qu’il intègre le bootstrap et ajoute un petit message si l’on ne s’en sert pas correctement.
Je n’ai pas la main sur le nom de l’image, puisque ce sont les paramètres du gitlab-ci qui fixent le nom et le tag, mais j’ai prévu dans le dernier push que j’ai fait que celle-ci s’appelle duniter/release-builder:17.12.1. Quoi qu’il en soit, il serait bien de lui donner un nom qui commence par duniter/ car c’est l’espace de nommage à utiliser sur DockerHub, mais si vous voulez lui mettre un autre nom que celui que j’ai prévu, prévenez-moi, et je modifierai le script de génération de Duniter en conséquence.
Aucun problème. Par contre, peux-tu me rétrograder en developer ? Je suis actuellement master sur ce groupe.
C’est bon, duniterteam est propriétaire de l’organisation duniter.
Merci en tous cas pour vos encouragements, ça me fait bien plaisir d’apporter ma pierre à cet édifice de monnaie libre. J’espère bien que j’aurai un jour l’occasion de vous rencontrer en chair et en os, même si je ne m’éloigne que très rarement d’Annecy…
1 Like
je ne comprend pas bien, peut tu etre plus clair ?
Pour le tag qui sera donc utilisé dans la config gitlab-ci du dépôt duniter on peut mettre le tag qu’on veut, si le / est autorisé on peut choisir le tag duniter/release-builder sans problème.
Le nom du dépôt est pour l’instant docker/duniter-releases, on peut le modifier par docker/duniter/release-builder ce qui donnera une image sur notre registry au nom de duniter/release-builder, c’est de ça dont tu parle ou je n’ai pas compris ?
Aussi peut tu modifier le gitlab ci du dépôt de l’image docker pour qu’en cas de push d’un tag, l’image soit déployée sur DockerHub en plus de notre propre registry ?
Je viens de le faire, c’est de ma faute j’ai tendance a faire confiance un peu facilement 
1 Like
Oui, c’est bien cela, avec comme tag la version 17.12.1, si cela vous convient (17.12 pour année et mois, et 1 parce que c’est la première du mois).
Je pense qu’il faut ajouter un docker login avec duniterteam (et donc ajouter le mot de passe correspondant dans les variables secrètes du CI) et faire un simple docker push ensuite, mais je préfère vous laisser faire. @cgeek qui a posé le gitlab-ci doit sûrement mieux savoir faire que moi.
Notez que j’ai déjà déployée l’image sur DockerHub, au cas où vous en avez besoin.
C’est plutôt @florck qui maîtrise GitLab CI et qui a pratiquement tout mis en place.
Fait : docker / duniter / release-builder · GitLab
Ça par contre je ne sais pas faire, peut-être @florck ?
Je pense qu’il faut ajouter (en dessous des lignes similaires) :
- docker tag "$CI_REGISTRY_IMAGE:$CI_BUILD_TAG" "$CI_PROJECT_PATH:$CI_BUILD_TAG"
- docker login -u "duniterteam" -p "$DUNITERTEAM_PASSWD"
- docker push "$CI_PROJECT_PATH:$CI_BUILD_TAG"
- docker push "$CI_PROJECT_PATH"
Mais je ne suis pas sûr, je ne maitrise pas très bien les variables pré-définies de GitLab CI et les docker push.
Bien sûr, il faudra ajouter la variable secrète DUNITERTEAM_PASSWD avec le mot de passe de duniterteam pour DockerHub à la configuration du projet.
En fait il faudra retagguer (docker build -t adresse_docker_hub:$CI_BUILD_TAG) puis pousser ce tag.
Par contre vu que c’est une image purement technique, je ne vois pas l’intérêt de la pousser sur le hub…
1 Like