trouver comment intégrer une VM-VirtualBox Windows dans docker et la piloter depuis gitlab-CI, et faire de même pour le build ARM.
Laisser tourner une VM Windows et une machine ARM accessible par réseau, et pouvoir déclencher la récupération du source et le build par réseau depui gitlab-ci.
Avoir des runner gitlab spécialisés pour Arm et Windows, qui tourne dans les environnements adéquats (ou qui sont des runner type VM et non des runner type Docker.
La première solution me plais le plus pour pouvoir faire tourner la CI sur n’importe quel serveur gitlab ou presque, ceci dit, la 3ème solution me semble la plus simple à mettre en place et celle qui sera la mieux maintenu par la communauté gitlab.
Il serait intéressant de mutualiser ces travaux avec les builds de Sakia, qui dépendent eux aussi de Appveyor et Travis pour les release linux et windows.
Pour Windows, ça me semble assez simple si VirtualBox accepte de tourner sans interface graphique, piloté par Vagrant. Honnêtement je ne suis pas certain de mon coup n’ayant jamais fait le test, mais vu l’idée derrière Vagrant, je ne vois pas pourquoi ce ne serait pas possible.
Pour ARM, il me semble que c’est “”“juste”"" de la cross-compilation, non ?
Sinon, sur serveur, il me semble que KVM/Qemu soit plus adapté que Virtualbox. C’est natif linux. A voir suivant ce qui demande le plus de travail d’intégration…
Ce qui me fait pencher pour VirtualBox plutôt que KVM/Qemu, c’est le fait que les gitlab-runner (qui marche de pair avec gitlab-ci) ont un mode VirtualBox et pas Qemu.
Vous avez avancé sur ce sujet ? même juste dans la réflexions ?
Pour l’ARM, je me demandais si on pouvait installer un docker et runner sur un Rasp pour que la CI fasse sont boulot dessus. J’ai un Asus Tinker qui est un peu plus costaud qu’un Rasp (2Go de RAM et un CPU un peu plus gros).
C’est possible il me semble, après le must serait quand même que la CI tourne sur les serveurs afin de ne pas être bloqués si ta machine est indisponible. Et puis ça pose des problèmes de sécurité chez toi si on peut exécuter des commandes sur une de tes machines.
Oui, et vous allez m’entendre si vous pourrissez à ma connexion ADSL en carton en téléchargeant des gros paquets (au hasard Qt et PyQt)
Ben on peut faire un POC chez moi et si ça marche je le met en hébergement chez Tétaneutral (un hébergeur associatif toulousain), il aura son IP publique.
J’ai commencé à fouiller sur comment faire de la cross compilation depuis linux pour une cible windows. Je n’ai rien trouvé de simple, mais ça n’est pas décourageant pour autant, du coup, j’ai bon espoir d’arriver à quelque-chose dans les semaines qui viennent, selon quand j’y re-consacre du temps.
Avec un peu de chance, si je trouve comment faire pour windows, il n’y aura que quelques lignes à changer pour arm (voir moins de chose à faire vu que c’est vers du linux arm donc libre aussi, pas besoin de télécharger des dll spécifique à mettre à dispo lors du build).
Ben pour sakia, pyinstaller te fait un blob. et le libsodium dedans est compilé.
J’ai pas essayé de le mettre sur mon raspi mais je ne pense pas que ça marche.
Edit: D’ailleurs il y a pas de wheel PyQt dispo pour ARM, et il y a pas le package sources https://pypi.org/project/PyQt5/#files . On va s’amuser si on veut faire un paquet pour Raspberry
Je confirme le “pas qu’un peu”, car non seulement il y a 4 modules C++ à compiler, mais il y a même une recompilation supplémentaire sur Windows pour node-webkit (l’enrobeur permettant de rendre Duniter utilisable comme application de Bureau).
À noter que c’est vraiment la plateforme Windows qui m’a demandé de m’arracher les cheveux, c’était vraiment l’étape pénible. ARM c’était le paradis en comparaison.
[/troll]