essayer d’ajouter la génération automatique de la version ARM dans le Gitlab-ci ;
revoir le processus de génération Gitlab-ci.
Je me demande aussi s’il ne serait pas intéressant d’avoir une version .tar.gz pour le serveur (aujourd’hui, il n’y a qu’un paquet pour Debian). Je pense que ça pourrait être utile pour l’image Docker… Quoi que, si j’utilise Alpine Linux, j’aurai une MuslC à la place de la GlibC, donc une version compilée risque de ne pas être compatible.
Je me demande également s’il ne faudrait pas faire un peu de ménage par rapport aux branches sur Gitlab. La branche DockerBuild n’a pas été supprimée (elle est même protégée) alors que son contenu est maintenant sur la branche 1.6. Et je pense qu’il serait judicieux de renommer la branche 1.6 en master. Mais dans ce cas, quel nom donner à master ?
@elois, @cgeek, ou d’autres, avez-vous des avis sur tous ces sujets ?
Je pense au contraire qu’on devrait faire comme @nanocryk sur le dépot duniter-rs, cad supprimer purement et simplement la branche master. Ainsi grâce aux branches de versions majeures, on sait tout de suite a quelle version correspond chaque doc.
La branche DockerBuild aurait du être supprimée automatiquement lors du merge, elle ne l’a pas été car je l’ai protected, c’était nécessaire pour les tests, je viens de la supprimer manuellement.
Oui, oui oui et oui
EDIT : @sveyret pour nous faire des penses-bêtes, nous avons l’habitude de nous créer une issue et de nous l’auto-assigner, ça évite d’encombrer le forum
La branche 1.6 restera, ne serait-ce que pour les versions correctives. C’est vrai que c’est plutôt master qui sert peu, sauf à se voir merger le contenu de la branche officiellement en prod.
Il est quand même bien d’avoir une branche master pour que le néophyte sache quel est le point de développement le plus avancé… Bon, sinon, on peut effectivement nommer à chaque fois les branches, et indiquer que la 1.6 est la branche par défaut.
Effectivement. Là, je voulais avoir des retours, mais c’est vrai que c’est également possible sur un ticket d’incident gitlab.
Ce qui se fait habituellement, c’est d’avoir la branche en cours qui s’appelle master. C’est au moment où l’on prépare la version suivante (1.7) que l’on crée une branche particulière pour la maintenance. Si j’ai bien compris, la 1.6 devrait sortir officiellement prochainement, donc c’est pour la future 1.7 qu’il faudrait re-créer une master.
Non, j’utilise une image Docker qui contient une chaine de compilation adaptée (en compilation croisée). C’est assez facile à faire sur Gentoo (avec crossdev).
oui en fait si aucun problème n’est rencontré la version releasée ce soir sera l’officielle !
Je trouve ce workflow pas clair. Le problème c’est que certain developpement pour la 1.7 ont déjà été commencés depuis longtemps (par exemple sur ma branche exp/ws2p-v2 ) et puis on ne se souviens jamais vraiment a quel version correspond master, si c’est juste pour une histoire d’accueil des néophytes il vaut mieux se concentrer sur la doc, le wiki, l’accueil sur le forum tout ça
J’ai une branche dev principale et des branches de features. Mes release se font avec des tags. C’est tout.
J’ai supprimé master car le dépot contient plusieurs projets qui ont chaqu’un des numéros de versions différents, du coup les merges sur master seraient trop compliqués à gerer avec un seul des dossiers a merge.
Disons que c’est plus adapté si l’on ne sait pas quelle sera la prochaine version, ce qui peut être très courant (va-t-on faire une 1.7 ou une 2.0 ?) Mais comme je disais, si vous vous sentez plus à l’aise avec des branches nommées, on peut simplement indiquer (paramétrage de gitlab) que la branche de la version en cours est la branche par défaut.
Justement, on a estimé avoir stabilisé les fonctions 1.6 et donc on a créé sa branche pour la release + maintenance. En théorie on pourrait déjà merger la 1.6 sur master, mais comme on a encore besoin de tester, l’opération reste en suspens.
Branche dev : C’est la branche qui correspond toujours à la dernière pre-release déployée… Elle reçoit la branche de la prochaine version en pre-release. Merger sur elle déclenche le déploiement d’une pré-release.
Branche master : C’est la branche qui correspond toujours à la dernière release stable déployée… Elle reçoit la branche dev finalisée pour la dernière version officielle. Merger sur elle déclenche le déploiement d’une release.
Branche version : rassemble les features avant le merge sur dev.
Branches XXXX : branches feature avant leur merge sur version.
Cela fonctionne tant qu’on n’avance pas sur deux versions en parallèle, par exemple nous allons développer la 1.7 et la 2.0 simultanément, car la 2.0 implique de très nombreux changements et sera longue à réaliser, mais bénéficiera tout de même des développements de la 1.7, qui est en cours également.
Je suis en train de voir si je peux faire un système automatisé de pre-release/release qui fonctionnerait un peu comme sur GitHub. Pour cela, j’ai cloné le dépôt et j’aurai besoin d’avoir accès aux mêmes runners (ou à des clones) que sur le dépôt initial (redshift et redshift-duniter-builder). Est-ce que l’un de vous peut m’arranger cela ?
Effectivement, à bien y regarder, je pourrai m’en passer, mais ça m’obligerait à faire des modifications dans le gitlab-ci.yml que je risquerais ensuite d’oublier d’annuler avant d’importer dans le projet principal…
