search

YesWiki / yeswiki

YesWiki is a wiki system written in PHP, including extensions making collaboration more simple (databases, maps, easy editing, bootstrap themes,...).
https://yeswiki.net
GNU Affero General Public License v3.0
109 stars 56 forks source link

Proposition de gestion des releases #901

Closed seballot closed 2 years ago

seballot commented 2 years ago

Voilà là proposition qu'on fait avec florian :

On garde le système actuel de build de version (https://github.com/YesWiki/yeswiki-build-repo + https://github.com/YesWiki/yeswiki-config-repo/blob/master/repo.config.json)

On utiliserait maintenant 2 versions (en plus de cercopitheque)

Pour le nom de ces deux versions, soit on continue un naming aligné sur les version majeure (perso je pense que c'est le plus simple) version stable: "doryphore" version test: "doryphore-test" puis on aura pareil avec ectoplasme

Soit on prend un nom generique et on assure le passage d'une version majeure à une autre version stable : "stable" version test: "test"

Pour les commits :

Intégration continue

Si on se chauffe, y'a l'idée de déclencher le build des versions dès que y'a un push sur doryphore ou un nouveau tag créé. On pourrait même mettre à jour automatiquement testing.yeswiki.net avec la version test dès que y'en a une publiée

Voilà pour les grandes, lignes, ça vous botte?

mrflos commented 2 years ago

Yes, ayant pu montrer et discuter avec Sebastian en amont pour ce process, je suis d'accord avec cette proposition!
Merci de l'effort @seballot !

Après, 3 remarques :

J9rem commented 2 years ago

Merci @mrflos et @seballot pour cette proposition. J'ai besoin d'éclaircissement sur la proposition car je ne comprends pas tout. Est-ce qu'il est proposé deux versions ou trois versions ?

Quel est le comportement proposé pour {{update}} ?

Je suppose que le comportement de {{update version="nomdeversion"}} permet toujours de choisir une autre version que celle installée.

J9rem commented 2 years ago

tout ce que l'on peut automatiser doit l'etre, on gagnera du temps! (je suis chaud pour le passer ce temps)

J'ai des pistes à partager pour la mise en place de ceci aussi.

J9rem commented 2 years ago
Juste un point d'information sur le nommage des versions sur repository : on peut utiliser doryphore-dev, tout s’appellera doryphore-dev (ex: nom du fichier yeswiki-doryphore-dev-2022-01-02-4.zip, nom du paquet pour l'argument target pour le repo-builder : yeswiki-doryphore-dev) mais en raison de la méthode de détermination du nom de dossier dans le .zip (cf. code) le dossier s'appellera doryphore sans le -dev. Des exemples (quelque soit le nom de la branche ou du tag concerné): Nom du paquet Nom du fichier Nom du dossier dans le .zip
cercopitheque yeswiki-cercopitheque-2022-01-01-3.zip cercopitheque
doryphore yeswiki-doryphore-2022-01-01-3.zip doryphore
testing yeswiki-testing-2022-01-01-3.zip testing
doryphore-dev yeswiki-doryphore-dev-2022-01-01-3.zip doryphore
stable-yeswiki yeswiki-stable-yeswiki-2022-01-01-3.zip stable

Heureusement, la méthode de mise à jour est très robuste pour ce nommage : elle prend le premier dossier trouvé dans le .zip donc pas de bugs à attendre mais ça peut perturber si on s'attendait à trouver un nom de dossier différent.

C'est juste pour information, ça ne perturbe a priori pas les nommages proposés

J9rem commented 2 years ago

En gros, si je comprends bien, nos aurions dans le fichier de config du dépôt:

{
  "cercopitheque": {
    "repository": "https://github.com/YesWiki/yeswiki",
    "branch": "cercopitheque",
    "description": "",
    "documentation": "https://yeswiki.net/?DocumentatioN",
    "extensions": {
...
   },
  "doryphore": {
    "repository": "https://github.com/YesWiki/yeswiki",
    "tag": "last-tag",  // <- action automatique à définir dans repo-builder pour l'attraper
    "description": "",
    "documentation": "https://yeswiki.net/?DocumentatioN",
    "extra-tools": {},
    "extra-themes": {
      "margot": {
        "repository": "https://github.com/YesWiki/yeswiki-theme-margot",
        "tag": "last-tag",  // <- action automatique à définir dans repo-builder pour l'attraper
      }
    },
    "extensions": {
      "lms": {
        "repository": "https://github.com/YesWiki/yeswiki-extension-lms",
        "tag": "last-tag",  // <- action automatique à définir dans repo-builder pour l'attraper
        "description": "Permet d'utiliser YesWiki comme une plateforme d'apprentissage (LMS : Learning Management System)",
        "documentation": "https://github.com/YesWiki/yeswiki-extension-lms/blob/master/README.md"
      },
      "webhooks": {
        "repository": "https://github.com/YesWiki/yeswiki-extension-webhooks",
        "tag": "last-tag",  // <- action automatique à définir dans repo-builder pour l'attraper
        "description": "Envoie des webhooks pour chaque ajout/modification/suppression d'une fiche Bazar",
        "documentation": "https://yeswiki.net/?DocumentationExtensionWebHooks"
      },
...
  },
  "doryphore-test": {
    "repository": "https://github.com/YesWiki/yeswiki",
    "branch": "doryphore",
    "description": "",
    "documentation": "https://yeswiki.net/?DocumentatioN",
    "extra-tools": {},
    "extra-themes": {
      "margot": {
        "repository": "https://github.com/YesWiki/yeswiki-theme-margot",
        "branch": "master"
      }
    },
    "extensions": {
      "lms": {
        "repository": "https://github.com/YesWiki/yeswiki-extension-lms",
        "branch": "doryphore",
        "description": "Permet d'utiliser YesWiki comme une plateforme d'apprentissage (LMS : Learning Management System)",
        "documentation": "https://github.com/YesWiki/yeswiki-extension-lms/blob/master/README.md"
      },
      "webhooks": {
        "repository": "https://github.com/YesWiki/yeswiki-extension-webhooks",
        "branch": "doryphore",
        "description": "Envoie des webhooks pour chaque ajout/modification/suppression d'une fiche Bazar",
        "documentation": "https://yeswiki.net/?DocumentationExtensionWebHooks"
      },
...
  "stable": {
    "repository": "https://github.com/YesWiki/yeswiki",
    "tag": "last-tag",  // <- action automatique à définir dans repo-builder pour l'attraper
    "description": "",
    "documentation": "https://yeswiki.net/?DocumentatioN",
    "extra-tools": {},
    "extra-themes": {
      "margot": {
        "repository": "https://github.com/YesWiki/yeswiki-theme-margot",
        "tag": "last-tag",  // <- action automatique à définir dans repo-builder pour l'attraper
      }
    },
    "extensions": {
      "lms": {
        "repository": "https://github.com/YesWiki/yeswiki-extension-lms",
        "tag": "last-tag",  // <- action automatique à définir dans repo-builder pour l'attraper
        "description": "Permet d'utiliser YesWiki comme une plateforme d'apprentissage (LMS : Learning Management System)",
        "documentation": "https://github.com/YesWiki/yeswiki-extension-lms/blob/master/README.md"
      },
      "webhooks": {
        "repository": "https://github.com/YesWiki/yeswiki-extension-webhooks",
        "tag": "last-tag",  // <- action automatique à définir dans repo-builder pour l'attraper
        "description": "Envoie des webhooks pour chaque ajout/modification/suppression d'une fiche Bazar",
        "documentation": "https://yeswiki.net/?DocumentationExtensionWebHooks"
      },
...
  },
  "testing": {
    "repository": "https://github.com/YesWiki/yeswiki",
    "branch": "branch-for-something-in-test",
    "description": "",
    "documentation": "https://yeswiki.net/?DocumentatioN",
    "extra-tools": {},
    "extra-themes": {
      "margot": {
        "repository": "https://github.com/YesWiki/yeswiki-theme-margot",
        "branch": "master"
      }
    },
    "extensions": {
      "lms": {
        "repository": "https://github.com/YesWiki/yeswiki-extension-lms",
        "branch": "doryphore",
        "description": "Permet d'utiliser YesWiki comme une plateforme d'apprentissage (LMS : Learning Management System)",
        "documentation": "https://github.com/YesWiki/yeswiki-extension-lms/blob/master/README.md"
      },
      "webhooks": {
        "repository": "https://github.com/YesWiki/yeswiki-extension-webhooks",
        "branch": "doryphore",
        "description": "Envoie des webhooks pour chaque ajout/modification/suppression d'une fiche Bazar",
        "documentation": "https://yeswiki.net/?DocumentationExtensionWebHooks"
      },
mrflos commented 2 years ago

Est-ce qu'il est proposé deux versions ou trois versions ?

* `doryphore` (dite stable) + `doryphoretest` (dite pour les tests)

* ou `doryphore` (dite stable) + `doryphoretest` (dite pour les tests) + `doryphoredev` (dite pour les dev non encore testés totalement)

Pour moi l'idée c'est d'avoir les 2 seulement, la doryphore-test étant pour valider que les dev sont assez stables pour faire une livraison en prod, mais cela n'empechera pas de créer un dépôt sur mesure pour tester une feature très alpha (comme j'ai fait avec les commentaires et le canal testing), mais c'est plus épisodique.
Le besoin premier c'est de s'assurer de la stabilité des sorties, car notre process de livraison est clair

Quel est le comportement proposé pour {{update}} ?

* Mettre à jour vers la version qui porte le même nom que celle installée (fonctionnement actuel)
* Pointer vers le dernier `tag` ?

C'est la partie laissée a trancher dans la proposition: soit faire un canal stable, qui fait les sauts de version, soit demander de passer à la version suppérieur en changeant explicitement de canal pour passer de doryphore à ectoplasme

* Pointer vers le dernier commit de `doryphore` ?

Non, doryphore sera avec des versions taguée

* Pointer vers le dernier commit de `doryphoretest ` ?

oui

Je suppose que le comportement de {{update version="nomdeversion"}} permet toujours de choisir une autre version que celle installée.

oui

mrflos commented 2 years ago

J'ai des pistes à partager pour la mise en place de ceci aussi.

Ok, n'hésites pas a les partager pendant qu'on est sur les specs, et j'aurais une proposition pour toi car j'ai l'impression que tu t'uses pas mal a suivre tous les chantiers : ne pas hésiter a aussi lâcher prise et déléguer sur certains aspects.
L'idée c'est de bien se mettre tous d'accord, mais pour moi, on n'est pas obligés de tous suivre le chantier, ni de tous le mettre en œuvre. Profitons en pour se répartir les taches et se soulager de la charge mentale d’être sur tous les fronts. Cela n’empêche en rien de faire les revues de codes, hein, juste cela éviter de créer de suite un gros chantier

mrflos commented 2 years ago

En gros, si je comprends bien, nos aurions dans le fichier de config du dépôt:

J'ai pas encore réfléchi a cela mais en effet, pour les repos à numéro de version, il faudra soit faire des mises a jour auto des tags lors des releases, soit faire la modification du fichier de conf du repo pour changer les tags ou il faut, soit bien tout poser dans le composer et la modification du composer pourrait générer le build du repo.
Le dépot stable disparaitrait dans l’hypothèse où l'on resterait sur des canaux doryphore (avec tags) / doryphore_test (avec branches) / ectoplasme (avec tags) / ectoplasme_test (avec branches)

J9rem commented 2 years ago

soit faire la modification du fichier de conf du repo pour changer les tags ou il faut

cette solution présente l'avantage d'être déjà disponible dès maintenant à la main. Je me dis que ça peut-être une bonne chose de partir sur ce process d'abord manuel et le passer en automatique (via composer ou par le dépôt ou , ....) par la suite

J9rem commented 2 years ago

Ok, n'hésites pas a les partager pendant qu'on est sur les specs,

Nous pourrions stabiliser HttpRequest::isHook pour bien prendre en compte le hook depuis Github incluant un SECRET

j'aurais une proposition pour toi : ne pas hésiter a aussi lâcher prise et déléguer sur certains aspects

Message reçu, je vous laisse tranquille et je continue de m'occuper que de ce qui m'impacte directement.

mrflos commented 2 years ago

Nous pourrions stabiliser HttpRequest::isHook pour bien prendre en compte le hook depuis Github incluant un SECRET

Oui grave, c'est difficile a tester, mais oui, faut le faire!

J9rem commented 2 years ago

C'est la partie laissée a trancher dans la proposition: soit faire un canal stable, qui fait les sauts de version, soit demander de passer à la version suppérieur en changeant explicitement de canal pour passer de doryphore à ectoplasme

Je n'aime pas forcer les gens à changer de version majeure sans avoir le choix mais pour des questions de sécurité et de maintenance c'est bien aussi. Donc pas de préférence.

Donc si uniquement deux versions, du genre:

mrflos commented 2 years ago

soit faire la modification du fichier de conf du repo pour changer les tags ou il faut

cette solution présente l'avantage d'être déjà disponible dès maintenant à la main. Je me dis que ça peut-être une bonne chose de partir sur ce process d'abord manuel et le passer en automatique (via composer ou par le dépôt ou , ....) par la suite

Bien d'accord avec ca: dans un premier temps, tagguer les extensions et le cœur, puis modifier a la main le fichier de conf des repo (et faire du CI pour que lors d'un changement de la configuration des repo, ca re-build tout seul).

Ce me fait penser, @J9rem , on a discuté avec @seballot de remettre la conf du repo dans le code de build du repo, plutôt qu'un repo conf séparé (il y avait une raison historique, mais je ne m'en souviens plus..).
On pourrait faire un mécanisme d'une config avec un nom genre .local.json qui prendrai le dessus sur la conf de base si elle existe, histoire d'avoir la conf utilisée par yeswiki et toujours la possibilité de faire une custom, qu'en pensez vous?

J9rem commented 2 years ago

remettre la conf du repo dans le code de build du repo

Oui c'est mieux car c'est plus facile pour assurer la maintenance (le build repo sachant quel format trouvé dans le fichier de config au bon format)

histoire d'avoir la conf utilisée par yeswiki et toujours la possibilité de faire une custom, qu'en pensez vous?

actuellement, le fichier de config est choisi par le fichier config.php avec un lien vers un fichier public. Je ne pense pas qu'il soit nécessaire de modifier quelque chose. Si quelqu'un veut une config custom, il lui suffit de proposer le fichier .json sur une url publique et de régler son config.php

mrflos commented 2 years ago

Bref, je propose que aucun commit sur doryphorene soit fait sans PR et que la version du dépôt doryphore-test ne pointe pas vers le dernier commit de doryphore mais de doryphore-dev afin de ne pas permettre ce souci.

Je suis OK pour la relecture systématique sur la branche doryphore (mais a voir si on aura vraiment les disponibilités pour le faire, et faut être conscients que cela ne bloquera pas tous les effets de bords).

Par contre pour moi doryphore-test pointe bien vers le dernier commit de doryphore, car il faut pouvoir tester exactement la version qui est candidate à être tagguée et releasée.

seballot commented 2 years ago

Yop,

concernant les risques évoqués https://github.com/YesWiki/yeswiki/issues/901#issuecomment-1034766470 tout est facilement gérable si on est à l'aise avec git

par exemple sur l'exemple de

un gentil hacker nous fait remonter un souci et nous le corrigeons en urgence sur les branches

Si on a publié 4.2, que entre temps on est en train de préparer 4.3 et donc la branche doryphore contient des commits en test (doryphore est "devant" 4.2). Si on doit faire un fix de sécurité il suffit de :

Pour info habituellement on utilise trois branches séparées (dev / test / prod) ce qui évite ce genre de force push. Mais là pour faire plus simple on a dit qu'on gardait que deux (dev = doryphore-dev / test = doryphore / prod = tag dans doryphore). Les problèmes listés sont toujours solvable, faut juste bien s'y retrouver :)

gatienbataille commented 2 years ago

de dieu, j'aurais dû lire ce matin : y avait que deux posts :-) bon cela dit, je comprends le propos général sans piger les astuces, ni risques fins des pr cherry push mergé repo-buildé mais je vous fais confiance. Il faudra qu'une fois la décision prise, nous réalisions une doc clair pour les users et users avancés, histoire que chacun comprenne bien les tenants et aboutissants de chaque version et des risques qu'il prend à jouer en doryphore-test par ex Merci pour ce travail en tout cas, j'espère pouvoir aider quelque part (mais clairement ce sera pas ici ;-)

J9rem commented 2 years ago

@seballot je suis d'accord qu'il est possible de faire ce que tu proposes techniquement. Humainement, je trouve qu'il est compliqué de savoir ce qui est validé ou pas encore sur doryphore et je me mets à la place d'un développeur débutant en git qui arrive dans l'équipe pas évident cette suite de manip. et donc je trouverai plus simple d'avoir simplement une branche supplémentaire doryphore-test, ce qui évite les quiproquo problématiques et la branche doryphore ne contient que ce qui a été testé. Du coup facile pour les actions.

  1. doryphore-dev
  2. doryphore-test reçoit ce qui doit être testé + les commit de bugfix
  3. doryphore ne reçoit que ce qui est testé ou les commits d'urgence anti hacking + les tags

Je sais que c'est chiant de voir 3 branches mais ça me semble plus simple à gérer que faire des revert, cherry-pick, force-push sur la branche master, ... ça me fait penser qu'il va y avoir des erreurs.

seballot commented 2 years ago

moi ça me va d'avoir trois branches, c'est ce que je disais à la fin de mon post c'est la manière classique. Florian était plus chaud pour en avoir que deux. moi je m'en fiche

Mais faut pas se leurrer y'aura quand meme des manips git pour gérer ces trois branches :)

Et puis aussi on saura jamais vraiment ce qui est testé, à moins d'avoir des procédures de tests par issue/PR, ce qui demanderait beaucoup plus (trop) de temps / procédures etc... Là on fait déjà un gros bon en avant : avoir une pre release pour éviter le déploiement de gros bugs

acheype commented 2 years ago

Hello, Juste pour dire que ça me parait une très bonne idée que les nouvelles features soit systématiquement testées par les plus impliqués de la communauté avant de les passer en prod. Ça peut en effet éviter de mauvaises surprises ! Et ok de mon côté pour vos specs, que ce soit 2 ou 3 branches. Good job !

J9rem commented 2 years ago

Donc @mrflos @acheype @seballot si je résume on partirait sur ceci (solution pour laquelle je peux vivre avec même si ça n'est pas ma préférée)

seballot commented 2 years ago

yep c'est bon pour moi !

J9rem commented 2 years ago

Au fait, si j'ai le retour positif d @acheype , je propose de traduire ma proposition en .md et de la mettre en documentation dans le dépot YesWiki/yeswiki-build-repo. Je me chargerai volontiers de déplacer le fichier de conf vers ce dépôt et de mettre à jour en conséquence notre dépôt de .zip yeswiki et de créer les branches manquantes.

Par contre, est-ce que chaque développeur actif sur un thème, une extension, peut créer un tag s'il y en a pas ? (@mrflos pour yeswiki-extension-ferme, @mrflos pour yeswiki-extension-qrcode, @acheype pour yeswiki-extension-lms, @seballot pour yeswiki-theme-margot). S'il n'y a pas de tag, la PR qui permettra de créer les différentes config ne mettra pas les extensions ou thèmes sans tag dans les .zip des versions dites stables car pas de tag = pas stable, ..

acheype commented 2 years ago

ok pour moi. Juste deux questions :

J9rem commented 2 years ago

@acheype les modifications pour la définition du dépôt sont actuellement à faire dans ce fichier : https://github.com/YesWiki/yeswiki-config-repo/blob/master/repo.config.json Sur proposition de @mrflos , que j'appuie aussi, nous allons le migrer dans ce dossier : https://github.com/YesWiki/yeswiki-build-repo/ (J'aurais juste à mettre à jour la config locale de repository.yeswiki.net pour qu'il aille cherché le fichier au bon endroit).

les tags devront alors être mis à jour dans les versions doryphore et stable en s'assurant que le tag indiqué pour les extensions et thèmes reste compatible de doryphore et php 7.3 (alors que dans stable en cas de passage à ectoplasme (tag commençant par v5. les extensions et thèmes pourraient ne plus être compatibles doryphore ou php 7.3).

pour l'installation initiale, la page de téléchargement https://yeswiki.net/?PageCreer utilise une action custom {{buttondownload version="doryphore"}}. Je propose que le premier de ces boutons pointe vers stable au lieu de doryphore et on ajoute plus bas dans la page les boutons vers les versions doryphore et doryphore-test en précisant respectivement ("pour éviter le passage automatique à ectoplasme" et "pour tester en avance les prochaines fonctionnalités en beta")

est-ce que j'ai répondu à tes questions ? (je ne suis pas sûr)

acheype commented 2 years ago

Si, l'ensemble de tes précisions répond à mes interrogation, merci !

C'est juste ce passage automatique d'une version majeur à l'autre qui m'interroge. J'ai du coup relu le ticket et voici les extraits que j'ai trouvé concernant ce sujet :

Flo :

C'est la partie laissée a trancher dans la proposition: soit faire un canal stable, qui fait les sauts de version, soit demander de passer à la version suppérieur en changeant explicitement de canal pour passer de doryphore à ectoplasme

Flo :

Le dépot stable disparaitrait dans l’hypothèse où l'on resterait sur des canaux doryphore (avec tags) / doryphore_test (avec branches) / ectoplasme (avec tags) / ectoplasme_test (avec branches)

Jerem :

Je n'aime pas forcer les gens à changer de version majeure sans avoir le choix mais pour des questions de sécurité et de maintenance c'est bien aussi. Donc pas de préférence.

Je me demande du coup si on a bien statué sur le fait qu'on veut une branche "stable" en plus qui fait les sauts de versions majeures. Perso j'y vois plus des inconvénients que des avantages mais ne me considérant pas actif sur la partie support, je vous fais confiance pour le choix final.

J9rem commented 2 years ago

@acheype ta remarque est très pertinente l'existence de la branche stable qui permet les sauts de versions majeures de façon automatique. Effectivement, ce serait plus simple de ne pas l'avoir pour le côté maintenance. Mais je n'avais pas l'impression que c'était validé donc pour éviter de longues discussions j'ai fait une proposition qui inclut les deux possibilités avec ou sans saut de versions majeures. Donc je réitère la question avec un vote par :+1: :-1: (:eyes: = neutre) pour @mrflos @seballot (en partant du principe que @acheype a choisi :eyes: ):

mrflos commented 2 years ago

ok pour moi, il faudra juste réfléchir a un méchanisme qui indiquerait que des releases stables ectoplasme existent et indiquer comment basculer depuis doryphore vers ectoplasme.

J9rem commented 2 years ago

Pour ce mécanisme, on peut adapter l'action {{update}} à la main

acheype commented 2 years ago

je croyais que la mise à jour était liée à ce qui est défini dans le fichier de configuration à ce niveau : 'yeswiki_version' => 'doryphore', ce n'est pas le cas ? (et avec ce qui a été dit, je comprenais que {{update version="XXX"}}, venait redéfinir par dessus ce paramétrage)

J9rem commented 2 years ago

Oui c'est bien ceci @acheype . Juste que si on veut afficher un petit message à côté du bouton pour dire "nouvelle version disponible, tapez {{update version="ectoplasme"}} pour l'obtenir, les détails sur cette page", il faut modifier l'action update pour ajouter ce message (sans changer le mécanisme de mise à jour)

acheype commented 2 years ago

Ok je comprends, c'est vrai que ça serait pratique que l'action update puisse annoncer via un message qu'une mise à jour majeure est disponible et qu'il peut la provoquer de la sorte. Mais juste un dernier truc, je m'interroge juste si ce ne serait pas plus adapté de lui demander d'aller modifier le paramètre yeswiki_version du fichier de configuration via l'interface d'admin.

J9rem commented 2 years ago

On peut clore cette issue si j'ai bien compris, car la décision évoquée est en place, non ?

seballot commented 2 years ago

Yes !