Et de ce que je comprends de la démarche, il nous faudrait en fait un nouveau Runner spécialisé dans la livraison de Duniter pour Linux (desktop .deb, .tar.gz, server .deb, et versions pour Gentoo désormais) basé sur cette nouvelle image duniter/release-builder.
Ce Runner serait en effet protégé de façon qu’il ne se lance que sur des branches protégées, et s’occuperait donc automatiquement de créer les livrables sur push d’un tag de release.
Non, pas vraiment ; enfin, je ne crois pas, mais je ne maitrise pas complètement le processus de livraison. Le but est d’avoir une image Docker utilisée à la place de Vagrant pour générer les livrables. C’est moins lourd et plus facilement portable. Je ne pense pas qu’un nouveau runner soit nécessaire.
En ce qui concerne Gentoo, c’est une source based release, donc ce sont les sources qui sont téléchargées directement et compilées sur l’ordinateur du destinataire. Ce changement de livraison ne concerne donc pas cette distribution.
Même si ce n’est pas le but affiché, c’est la suite logique que j’y trouve : les livrables Linux pourraient être générés automatiquement sur détection d’un tag sur une branche protégée, donc forcément validée par un niveau Master ou Owner dans GitLab.
Mais bon, ce n’est pas la priorité, je le conçois 
Pour Gentoo, OK.
Bon, et bien, j’ai fait une nouvelle MR pour ajouter le déploiement sur DockerHub. En espérant que cela fonctionne bien.
L’intérêt c’est de permettre a ceux qui veulent compiler Duniter eux même de le faire dans un conteneur docker correctement configuré pour ça, typiquement les utilisateurs de gentoo mais pas que
Ok, l’argument se tient.
À noter cependant que la registry gitlab est suffisante pour ça, la seule différence apportée par le hub est la publicité.
C’est aussi que lorsque l’on fait un docker pull, sans aucune configuration particulière, c’est sur le Docker hub que l’image est recherchée.
et ? Toute façon il faut connaître le nom de l’image 
On est parti sur les scripts de démarrage automatique et on a un peu dérivé sur le remplacement de Vagrant par Docker… Je recentre donc le sujet. 
Même si les 2 MR que j’ai faites concernant le remplacement de Vagrant par Docker n’ont pas encore été acceptées, j’ai quand même utilisé cette méthode pour générer les paquets Debian et tester le fichier de service systemd sur une machine virtuelle Ubuntu. Suite à ces tests, j’ai apporté des corrections sur la MR qui concerne le démarrage automatique, et cela me semble bon maintenant. J’ai même essayé de faire un drop-in file pour ajouter la partie serveur Web et cela a bien fonctionné. 
Du coup, lorsque ce sera intégré, on pourra démarrer automatiquement Duniter en service sur Ubuntu. À ce moment-là, j’ajouterai un petit mot dans le mode d’emploi pour expliquer comment modifier le fonctionnement par défaut avec les drop-ins.
(et à part ça, bonne année à tous ! 
)
Personnellement, je suis incapable d’intervenir sur Duniter depuis mi-décembre, et ça risque de durer encore un bon mois.
Pour ne pas que tes MR tombent dans l’oubli (bon, normalement on a des notifications dans GitLab pour nous faire des rappels), n’hésites pas à nous relancer ici directement.
Si tu es trop occupé, est-ce que @elois pourrait valider ces MR ?
De mon coté, je vais également avoir beaucoup moins de temps cette année suite a d’importants changements de vie, j’espère que ce nouvel espace vide vas appeler de nouveaux contributeurs
@sveyret J’ai créer un runner avec le conteneur duniter/release-builder mais je ne sais pas quelles commandes je doit inclure dans le fichier de conf gitlab-ci pour tester les build lors du push d’un tag. J’ai ajouté le job en question avec le tag qui vas bien sur la branche test-ci-docker-build, peut tu remplir les commandes dans la partie script ?
Je l’aurais bien fait moi même mais je ne comprend pas quel script appeler. le script build.sh appelle docker, or du docker dans docker ça risque de mal se passer, peut être faut t’il appliquer directement le script build-deb mais je ne sais pas comment ! Peut tu regarder ça ?
en fait j’aimerais qu’on teste la build d’une release via notre serveur CI c’est pour ça
Effectivement, dans l’absolue, il faut appeler build.sh make deb, comme avant, mais cela va lancer un docker dans le docker. Il faut que j’étudie cela plus attentivement. J’ai trouvé un article intéressant sur le sujet, que je mets ici à la fois pour ceux que cela intéresse et pour m’en souvenir :
http://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/
Cela nécessitera de modifier le runner :
https://docs.gitlab.com/ce/ci/docker/using_docker_build.html#use-docker-socket-binding
@elois, en attendant, est-ce que tu as la possibilité de valider ma MR sur la partie Docker ? Il faudra bien ajouter la variable indiquée pour le mot de passe Duniter sur DockerHub.
@sveyret je viens de le faire, et le push sur docker hub ne fonctionne pas : build_image (#1011) · Jobs · docker / duniter / release-builder · GitLab
je vais séparer en plusieurs jobs avec le push sur docker hub en dernier pour que cette erreur ne bloque pas le push sur notre registry qui sera utilisé pour les build officielles 
@sveyret l’erreur venait du fait que le tag n’étais pas protected et donc la variable cachée ne s’activais pas, je viens de corriger ça mais j’ai une nouvelle erreur :
$ docker login -u "duniterteam" -p "$DUNITERTEAM_PASSWD"
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Login Succeeded
$ docker push "$CI_PROJECT_PATH:$CI_BUILD_TAG"
An image does not exist locally with the tag: docker/duniter/release-builder
The push refers to repository [docker.io/docker/duniter/release-builder]
ERROR: Job failed: exit code 1
Je suis en train de réessayer en remplaçant CI_PROJECT_PATH par CI_REGISTRY_IMAGE
Pourtant, le tag est fait juste au dessus du login avec les même paramètres… 
@sveyret alléluia j’ai réussi !!! 
Le problème viens du fait qu’il essayer de pusher sur le repot docker/duniter/release-builder sur lequel nous n’avons évidemment pas les droits, j’ai donc inscrit a la main duniter/release-builder de toute façon ce nom n’a pas vocation a changer
Effectivement, bien joué ! Tu as vu, j’ai mis un commentaire sur ton commit, parce que le docker tag juste au dessus du docker login n’est plus nécessaire.
oui vu et supprimé