ZEP-08 Utilisation de git pour gérer les tutos et articles

Avec création de PR depuis zds ou l'extérieur

a marqué ce sujet comme résolu.

Reprise du dernier message de la page précédente

Bonjour, je suis le mec de la ZEP-12 d'à coté qui parle également des tutoriels. Je viens soumettre une petite question : est ce que c'est plutôt ici ou plutôt sur la ZEP-12 qu'il faut discuter de ce qui doit être versionné et ce qui doit être conservé en base de donnée ? Si tel est le cas, je ferait une petite liste de ce qui est actuelement en rapport avec un tuto (bien que l'état des lieux de Firm1 donne déjà beaucoup d'infos).

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0
Auteur du sujet

Ici, on a tout ce qui doit être versionné, le modèle en bdd n'est pas concerné a priori. Je pense qu'il faut vraiment bien séparer les choses de ce point de vue. la ZEP 12 par le de refactorisation la ZEP 8 parle de l'utilisation de git pour versionner et collaborer.

+0 -0
Auteur du sujet

la thumnnail n'est pas versionnée au moins grâce au versionnage du manifest.json?

Ensuite versionner les images, pourquoi pas. Mais en soit une nouvelle version d'image = un nouveau lien la plupart du temps donc c'est de manière collatérale déjà versionné.

+0 -0

la thumnnail n'est pas versionnée au moins grâce au versionnage du manifest.json?

Non, c'est moi qui devait m'en charger, et j'ai décidé d'attendre le gros refactoring exprès pour pas avoir a le faire deux fois :)

Ensuite versionner les images, pourquoi pas. Mais en soit une nouvelle version d'image = un nouveau lien la plupart du temps donc c'est de manière collatérale déjà versionné.

artragis

Oui. Mais est ce qu'on versionne l'image elle meme (qui aurait un nom unique) ou juste le lien? Quid des autres images? (Qui sont actuelement liée a la gallerie, mais on peut les récupérer que une par une?).

Pour le reste :

  • versionne-t-on les auteurs? (Et comment?)
  • versionne-t-on les tags?
  • versionne-t-on autre chose ? On en est a refaire le machin, on peut se lacher un peu sur les idées folles.

A fortiori, qu'est ce qui reste en BDD. C'est indirectement le sujet! Les empreintes et branches vont pas aller dans le JSON ^^

Édité par pierre_24

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0

Pour le reste :

  • versionne-t-on les auteurs? (Et comment?)

pierre_24

Simple, il faudrait en fait que les commits soient fait par les auteurs. Suffira ensuite de voir quels auteurs ont fait quel commit.

  • versionne-t-on les tags?
  • versionne-t-on autre chose ? On en est a refaire le machin, on peut se lacher un peu sur les idées folles.

pierre_24

Simple : tout. Ou du moins au moins les images.

A fortiori, qu'est ce qui reste en BDD. C'est indirectement le sujet! Les empreintes et branches vont pas aller dans le JSON ^^

pierre_24

Simple à nouveau ; les sha de prod / beta (et encore ; une branche ? Bref une référence vers un object git). Le draft, faut comprendre "draft utilisé par le site", soit encore un objet git.

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+1 -0

Simple, il faudrait en fait que les commits soient fait par les auteurs. Suffira ensuite de voir quels auteurs ont fait quel commit.

Je sais pas dire si c'est une solution envisageable, d'autant si ça demande à terme de crawler tout les commits de toutes les branches pour checker. M'enfin je garde ça en tête :)

Simple : tout. Ou du moins au moins les images.

Quand tu parles des images, tu parles également des images du tuto/article ? Est que ça impliquerai à terme la création d'un dossier "media" ou "image" dans le repo du tutoriel pour le faire ?

Et de manière générale : j'apprécie vraiment l'emploi de git pour le versionnage (na!) des tutoriels et articles et je trouve que c'est vraiment un plus non-négligeable, que je soutiens à 200%.

Je tiens cependant à rappeler qu'un auteur lambda ne connait pas forcément git et ne tient pas forcément à le connaitre non plus (lui, ce qu'il veut, c'est écrire son tuto). Il faut donc pas trop complexifier la chose, au moins sur le ZdS même, pour que l'écriture d'un tuto s'apparente pas à la gestion de 10 branches parce que il y a 5 auteurs sur son cours (chiffre inventé, hein, j'ai pas compté ^^ ). Il faut donc également, selon moi, un vrai travail coté front pour que tout ça reste évident et naturel.

Je parle de ça parce que je tente de suivre le débat sur le nombre de branche et leur utilité. Je comprend qu'il est vraiment important de décider du workflow à suivre, le problème étant que je n'arrive pas à comprendre à quoi va aboutir ce débat. Une/deux/trois branches, qu'est ce qui va changer pour l'auteur ? pour le validateur ? Pour le lecteur ? Pour le mec qui va implémenter la chose ? Et je ne dis pas ça pour dire que votre débat sert à rien, mais parce que je tente vraiment de comprendre les tenants et aboutissant. Et je garde en tête que l'auteur se posera surement autant de questions du genre (dont la première sera "c'est quoi git, et pourquoi j'en aurais besoin", même si j'en suis plus à ce stade) :)

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+0 -0

Simple, il faudrait en fait que les commits soient fait par les auteurs. Suffira ensuite de voir quels auteurs ont fait quel commit.

Je sais pas dire si c'est une solution envisageable, d'autant si ça demande à terme de crawler tout les commits de toutes les branches pour checker. M'enfin je garde ça en tête :)

pierre_24

Peut-être juste de la branche principale ?

Simple : tout. Ou du moins au moins les images.

Quand tu parles des images, tu parles également des images du tuto/article ? Est que ça impliquerai à terme la création d'un dossier "media" ou "image" dans le repo du tutoriel pour le faire ?

pierre_24

Oui, des images du document (pour reprendre ton terme). Après l'organisation faite par l'application coté back, peu importe… Mais si on peut bidouiller via un dépot distant, comme on le fantasme depuis le début du développement de l'idée (à savoir, laisser un accès à un dépot distant pour mettre à jour son tuto, sans passer par l'interface donc), ça importe peu. L'extrait contiendra le chemin vers l'image (soit ![](./dossier/caca/image.png) par exemple). En bref, l'organisation est juste faite si le dépot est mis à jour par le back / l'appli.

Et de manière générale : j'apprécie vraiment l'emploi de git pour le versionnage (na!) des tutoriels et articles et je trouve que c'est vraiment un plus non-négligeable, que je soutiens à 200%.

Je tiens cependant à rappeler qu'un auteur lambda ne connait pas forcément git et ne tient pas forcément à le connaitre non plus (lui, ce qu'il veut, c'est écrire son tuto). Il faut donc pas trop complexifier la chose, au moins sur le ZdS même, pour que l'écriture d'un tuto s'apparente pas à la gestion de 10 branches parce que il y a 5 auteurs sur son cours (chiffre inventé, hein, j'ai pas compté ^^ ). Il faut donc également, selon moi, un vrai travail coté front pour que tout ça reste évident et naturel.

Je parle de ça parce que je tente de suivre le débat sur le nombre de branche et leur utilité. Je comprend qu'il est vraiment important de décider du workflow à suivre, le problème étant que je n'arrive pas à comprendre à quoi va aboutir ce débat. Une/deux/trois branches, qu'est ce qui va changer pour l'auteur ? pour le validateur ? Pour le lecteur ? Pour le mec qui va implémenter la chose ? Et je ne dis pas ça pour dire que votre débat sert à rien, mais parce que je tente vraiment de comprendre les tenants et aboutissant. Et je garde en tête que l'auteur se posera surement autant de questions du genre (dont la première sera "c'est quoi git, et pourquoi j'en aurais besoin", même si j'en suis plus à ce stade) :)

pierre_24

Comme je l'ai dit un peu plus haut, faut voir un peu qui va faire des tutos. Y'a les membres lambda qui vont passer par l'app. Dans ce cas, il s'en fiche un peu qu'il y ait 36 branches. Le plus important étant "version de draft" "version beta" et "version publiée". Ca peut être des tags, des branches, des références vers un sha1, … peu importe. Après si le type se sent d'humeur aventurière, bah c'est lui qui gère sa merde, et dit au back "voilà ce qu'est ma version de draft, celle que je voudrai mettre en beta, et voilà ma PR pour mettre en prod". Bref, une très grande flexibilité au final. Que ce soit du point de vue "auteur qui ne connait pas git, et n'a pas à le connaître s'il en a pas envie", et "keke qui sait ce qu'il fait", auquel cas on lui donne les outils pour. Soit un dépot distant et la possibilité de marquer ses versions au final.

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+0 -0

Les méta-données du tuto ne sont toute manière pas dans un fichier json lui-même versionné ? Pour le coup, il n'y aurait presque rien à versionner puisque tout l'est déjà (au point de vue métadonnées). La BD elle-même n'aurait qu'à stocker des hashes de commit pour savoir où on en est.

Canis Lupus pour vous servir

+2 -0

Pour relancer le machin, j'ai eu une illumination ce matin en chipotant dans le back : l'éventuelle branche de prod est inutile ! Je m'explique : au moment de la validation du tutoriel, celui-ci est parsé en HTML et conservé sous cette forme sur le serveur. Autrement dit, il ne reste aucune trace des fichiers originels, même le manifest.json est réécrit. Du coup, à quoi servirait d'avoir une branche de prod' contenant des fichiers markdown ne servant à rien ? Pour moi, ce qu'il faudrait avoir, c'est une référence à un commit de la branche de validation, si branche de validation il y a, et c'est emplement suffisant :)

#JeSuisToujoursArius • Doctorant et assistant en chimiedev' à temps partiel (co-réalisateur ZEP-12, recherche et template LaTeX)

+1 -0

Le problème étant que l'équipe des validos a parfois besoin de faire des hotfixes sur la prod. Donc, d'avoir un point d'entrée pour le faire, et regénérer les fichiers.

Tout comme, il y a besoin d'avoir un réceptacle pour les PR de validation, et aussi des gestion de droits évidentes. Si le tag se balade sur n'importe quelle branche, c'est la merde, vu qu'on ne peut mettre de la sécurité sur une branche particulière (ici la prod), et vu que la branche ayant le commit mis en prod peut changer…

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+0 -0

Concernant ce qui doit être versionné, pour moi, tout (markdown, ressources (images…) et méta donnes via les commits (auteur et valido) et le reste dans un/des manifestes. L'intérêt et le but est de pouvoir reconstruire les infos de db depuis le dépôt. Un dépôt devrait permettre de représenter entièrement un tuto de manière indépendante. La db ne devrait servir qu'a accélérer l'accès a ces données depuis le site mais le dépôt devrait être indépendant et représenter un tuto entièrement.

+1 -0
Auteur du sujet

alors, pour être vraiment précis, je vais tenter tant bien que mal de lister ce que "tout" veut dire:

au niveau d'un extrait :

  • le contenu
  • les images
    • quand on parle de versionner les images : les liens vers les images ou bien les tableaux de pixels?
  • le titre
  • validé/pas validé

au niveau de la partie/chapitre (ou conteneur si on regarde ZEP 12)

  • le titre
  • l'intro
  • la conclusion
  • validé/pas validé
  • l'ordre des enfants (extraits d'un chapitre/chapitre d'une partie)

Pour le conteneur général (tuto) :

  • le thumbnail
  • les différentes validations
  • l'ordre des enfants
  • la licence
  • le titre
  • l'introduction
  • la conclusion

Les personnes prenant part?

  • auteurs
  • validateurs

J'ai séparé ces deux choses car je ne vois pas l'intérêt de versionner ces choses ni en quoi cela rend le dépôt dépendant de zds. Au contraire, les validateurs, c'est ultra dépendant de zds. De même que l'état "validé/pas validé".

+0 -0

Les auteurs ça peut être vu comme les auteurs de commits et les validateurs comme les personnes qui ont merge une branche (git donne la possibilité de spécifier les 2 : auteur et commiteur). Le statut validé ou pas (et surtout quel version) devrait être géré via un tag et/ou branche.

+0 -0

Pour moi la première à laquelle il faut penser se sont les abus qui peuvent se présenter.

Les abus

Concernant l'ajout d'un dépot distant ils peuvent se présenter sous au moins 3 formes :

  1. Un dépot avec 10^9999999 fichiers de versionnés
  2. Un dépot avec un historique de de 10^999999999999999 commits
  3. Des fichiers interdits sont présents sur le dépot

Et il est impossible de traiter ces cas automatique avec git (pour le second il est toujours possible d'utiliser --depth, mais dans ce cas là on ne peut pas utiliser git log pour récupérer la liste des auteurs)

Donc concernant les deux premiers abus, la seule solution qui me viens à l'esprit pour gérer ça automatiquement c'est les quotas du système d'exploitation, ce qui implique soit de gérer des quotas par dossier (compliqué -pas impossible car rien n'est impossible =D- à mettre en place), soit d'avoir un utilisateur système par utilisateur inscrit (ce qui pose des problème de configuration important et surtout peut présenter un jolie travail supplémentaire si un jour il faut changer de serveur).

Bref dans tous les cas c'est l'admin sys qui pleurs.

Quand au troisième abus il suffirait de lancer un script une fois le dépot cloné.

Sinon une autre solution se serait de valider manuellement l'ajout d'un dépot distant, ainsi si "validateur" pourra vérifier que le dépot a une taille normal et que ça ne vas pas poser de problèmes et que tous les fichiers présents sont autorisés.

Enfin une dernière solution serait de forcer l'ajout d'un dépot vierge.

Quoi qu'il arrive le problème ne se pose que pour le clone car après tout peut être géré par un hook pre-receive et quelques commandes tels que du et un script shell.

Les auteurs

Ensuite se pose la question des auteurs, là je vois deux solutions : 1. Utiliser git log 2. Utiliser un fichier json

git log

L'utilisation de git log pose un problème fondamental : comment associer les auteurs des commits avec les utilisateur du site. La seule solution acceptable c'est de les forcer à configurer leur dépot local de manière à utiliser le même pseudo que sur le site (ou le même e-mail, ce qui est le fonctionnement de github).

Par contre git log peut être particulièrement lent si l'historique est grand mais dans ce cas on peut y aller de manière incrémentale (on génère et met en cache la liste des auteurs lorsque le dépot est cloné, puis un hook post-receive se charge de mettre à jour cette liste à chaque push).

Fichier json

Dans ce cas on se contente de laisser les auteur gérer la liste eux même, manuellement. Ils vont donc devoir remplir un fichier (json par exemple) avec la liste des pseudos des auteurs (les pseudos devant être ceux du site). De cette manière il devrait être possible de mentionner un auteur non inscrit sur le site.

Un mix des deux

On utilise git log, et un fichier json permet de faire la correspondance entre les auteurs des commits et les utilisateurs sur le site.

Les branches/tags

Ici je pense que la première chose à faire c'est de remettre à plat les besoins. Il faut : (n'hésitez pas à compléter la liste)

  • identifier la béta en cours (archiver la liste des bétas ?)
  • identifier la dernière version validée (archiver cette liste ?)
  • identifier la dernière version en cours de rédaction
  • les auteurs peuvent publier une béta, soumettre une version à la validation, modifier la version en cours de rédaction
  • les validateurs peuvent publier une version en validation
  • les validateurs peuvent modifier uen version publiée (attention aux conflits avec la CC-BY-ND et la CC-BY-NC-ND) ?
  • une utilisation identique via l'interface web et un client git traditionnel
Tout est identifié par un commit

La première chose qui me saute aux yeux c'est que tout correspond à un commit et que par conséquent tout est identifié de manière unique par un hash. Donc la première chose de faisable c'est de permettre de donner le hash précis de la version à mettre en béta/valider à chaque fois (le hash ou un alias, dixit un tag).

Archiver

La seconde chose c'est qu'il serait bien de pouvoir archiver cet historique de béta/validation auquel cas on peut avoir deux solutions :

  1. Les stocker dans la bd
  2. Utiliser des tags nommés avec une convention précise (ie: beta-<numero de la beta>, validation-<numero>, valide-<prod>)

Le premier cas étant trivial et classique je vais pas m'étendre. Quand au second il est plus complex et il présente un problème principal, à savoir la gestion des droits car :

  • seul l'auteur peut proposer en validation
  • seul l'auteur peut propsoer en béta
  • seul l'équipe de validation peut valider

Dans ce cas je vois deux solutions :

  1. Forcer l'utilisation de l'interface web pour créer les/ces tags (l'auteur indique le hash du commit ou un tag à mettre en béta/validation)
  2. Utiliser des hooks pre-receive (mais qu, à prioris, peuvent être abusés car il ne me semble pas que le hook connaisse l'utilisateur utilisé pour push)

De plus la seconde solution impose aussi d'utiliser un hook post-receive pour détecter ces tags et effectuer les actions correspondantes coté site web. Bref la première solution me semble être la plus viable.

Dans tous les cas il faudra protéger ces tags là afin d'empécher leur supression.

Les modifications effectuées par les validateurs

Dans ce cas je ne vois vraiment qu'une solution : si les validateurs doivent effectuer une modification alors, dans ce cas, une nouvelle branche est toujours créée à partir du commit de la version publiée (git checkout <hash> && git checkout -b validation-revision-<n>). Ainsi pas besoins de protéger la branche en écriture vue que HEAD n'est jamais utilisé. Par contre, par sécurité, il faut bloquer la suppression de cette branche (même si en réalité le commit existera toujours).

P.S Vous l'auriez compris, il me semble important d'être en mesure de manipuler directement le dépot git :) ou tout au moins d'être en mesure d'utiliser un dépot git distant que l'on peut donc manipuler.

Édité par Nicofuma

Développeur de phpBB

+1 -0

Voici les logs d'une conversation qu'on a eu sur IRC tout à l'heure (je le reformulerais et résumerais plus tard)

[16:22:25] <Nicofuma> mais encore la plupart des problèmes se posent si vous donnez accès au dépot hébergé sur els serveurs de zds
[16:22:25] <pierre_24> Ceci dit, je pense que tout le monde est près à aller de l'avant, donc énorme merci pour tout ça
[16:22:31] <Nicofuma> ou lors du clone d'un dépot distant
[16:22:50] <pierre_24> Nicofuma: si on ne donne pas ça, on pert énormément, selon moi
[16:23:04] <Nicofuma> le dépot distant c'est déjà énorme
[16:23:17] <Nicofuma> le dépot local… c'est vraiment compliqué
[16:24:05] <pierre_24> ça a l'air
[16:24:31] <pierre_24> problème du dépot distant, selon moi, c'est la gestion des droits
[16:25:04] <Nicofuma> ben justement non
[16:25:16] <Nicofuma> car dans ce cas c'est à l'auteur de els gérer
[16:25:31] <Nicofuma> et comme git conserve tous les commits
[16:25:37] <Nicofuma> vous avez pas de problèmes
[16:25:38] <pierre_24> Ouais, à ce niveau là, ok. Mais au moment de la validation …
[16:25:53] <Nicofuma> suffit de travailler avec un commit précis et non HEAD
[16:26:04] <Nicofuma> ou alors avec un tag (et dans ce cas il faut protéger les tags)
[16:27:02] <Nicofuma> mais j'en parle à un moment de ça, c'est vers la fin je crois
[16:27:20] <pierre_24> Oui, mais imagine qu'un validateur veuille créer une branche pour la correction orthographique
[16:27:34] <Nicofuma> alors tout b'adord
[16:27:43] <Nicofuma> si c'est sous CC-BY-ND il peut pas ^^
[16:27:59] <Nicofuma> sinon suffit de créer la branch systématiquement à partir du dernier commit validé
[16:28:18] <Nicofuma> ainsi l'auteur peut push des trucs sur la branche tu t'en moque
[16:29:03] <pierre_24> Juste pour être sur, explique un coup ce que tu entend par "dépot distant" ?
[16:29:15] <– Florian (1e0dfa6ddc4@Smooth-qobqsd.net) has quit (Ping timeout: 121 seconds)
[16:29:43] <Nicofuma> un dépot sur github par exemple, ou sur gitorious ou autre
[16:29:55] <Nicofuma> dans ce cas zds fait un clone local
[16:30:17] <Nicofuma> puis git fetch && git checkout <hash> à chaque fois
[16:30:34] <Nicofuma> et la branche de validation n'est jamais push
[16:30:39] <Nicofuma> elle reste locale
[16:32:05] <pierre_24> Ok, je vois. Ce qui à mon avis bloque les défenseurs d'un dépot local, c'est qu'à un moment, il faut aller envoyer des données sur un autre site. Donc des communications qui peuvent ralentir le machin
[16:32:20] <pierre_24> (sans parler du fait que je ne sais pas ce que ça implique coté code)
[16:32:50] <Nicofuma> en fait il y a jamais besoins d'envoyer les infos, juste de les récupérer
[16:32:58] <Nicofuma> après c'est sur que ça ralentis
[16:33:10] <Nicofuma> maisuniquement lors des beta/mise en validation
[16:33:17] <pierre_24> Ouais, mais faut aussi garder en tête l'interface web coté zds
[16:33:22] <Nicofuma> yep
[16:33:31] <Nicofuma> ils continuent de travailler avec un dépot local
[16:33:34] <Nicofuma> mais dans ce cas
[16:33:57] <Nicofuma> ça veut dire que l'interface et l'utilisation directe de git sont mutuellement exclusive
[16:34:30] <pierre_24> Ouais. Je vois déjà les gens te répondre non ^^
[16:34:57] <Nicofuma> dans ce cas c'est au sysadmin de faire le boulot ou alors c'est impossible
[16:35:06] <pierre_24> Moi, à la limite, ça me dérangerais pas que ce soit exclusif
[16:35:36] <Nicofuma> le vrai problème c'est si un gars veut passer d'un tuto commencé sur l'interface web à un tuto controllé à distance
[16:35:44] <pierre_24> exactement
[16:35:52] <Nicofuma> dans ce cas on pourrait imaginer un système en 2 temps
[16:36:06] <Nicofuma> 1er temps il récupère un liens vers le dépot local
[16:36:11] <Nicofuma> (en lecture uniquement)
[16:36:18] <Nicofuma> donc il clone en local
[16:36:24] <Nicofuma> et push en distant sur github apr exemple
[16:36:53] <Nicofuma> 2eme temps il migre le tuto sur zds en fournissant l'url distante
[16:36:58] <Nicofuma> dans ce cas 2 solutions
[16:37:23] <Nicofuma> 1) git remote add, et tu te casse la tête avec els branches & co si ça a été modifié entre temps
[16:37:38] <Nicofuma> 2) rm -Rf <dossier_du_tuto>/*
[16:38:12] <Nicofuma> && cd <dossier_du_tuo> && git clone <url distante> .
[16:38:31] <Nicofuma> un truc dans le genre
[16:39:14] <pierre_24> Ouais, je vois l'idée
[16:39:24] <pierre_24> c'est pas forcément simple non plus ^^
[16:39:50] <Nicofuma> oui mais bon c'est un cas qui reste quand même anecdotique je pense, surtout au début
[16:40:21] <Nicofuma> et au début comme t'as pas trop le temps pour développer un truc utiliser anecdotiquement il y a toujours moyen de le gérer manuellement
[16:40:46] <Nicofuma> mais ça implique de devoir dire non dans certains cas (du genre le mini tuto de 3 extraits)
[16:41:03] <Nicofuma> sinon tu peux rapidemment être débordé/en avoir marre :p
[16:41:06] <pierre_24> Mmmh. Faut savoir aussi que très peu de gens sont sys admin
[16:41:34] <pierre_24> et que quand ils sont là, ils ont d'autres chat à fouetter que de faire du github ^^
[16:41:38] <Nicofuma> ^^
[16:42:21] <Nicofuma> C'est compliqué comme question
[16:42:23] <pierre_24> Je pense que c'est entre autre pour ça que les gens cherchent une solution qui puisse se faire via interface web dans tout les cas
[16:42:53] <pierre_24> ça permet de pouvoir déléguer ça à des validateurs sans les laisser approcher une console
[16:43:30] <Nicofuma> En fait dans ce que je décris, le travail des validateurs se fait via l'interface web
[16:43:53] <Nicofuma> l'utilisation directe de git ne concerne que l'auteur qui a décidé de l'utiliser (et ce dès le début)
[16:44:08] –> Florian (1e0dfa6ddc4@Smooth-qobqsd.net) has joined #zds-dev
[16:44:16] <gustavi> salut Florian
[16:44:21] <pierre_24> ben le validateur va devoir faire remote et fetch a un moment
[16:44:27] <Florian> Salut Gustavi :)
[16:44:30] <Nicofuma> le site le fera pour lui
[16:44:32] <Nicofuma> salut
[16:45:00] <Florian> pierre_24 ou gustavi j'pourrais avoir un p'tit coup de main ?
[16:45:10] <pierre_24> Si tu veux ^^
[16:45:14] <Nicofuma> car dans tous les cas l'auteur utilise le site pour demander la mise en béta ou la mise en validation

Édité par Nicofuma

Développeur de phpBB

+0 -0

(À mon avis c'est pas une bonne idée de se servir de la liste des auteurs de commits pour les auteurs affichés parce que 1/ si le dépôt est distant, on ne retrouvera pas forcément l'utilisateur ici (email différent, etc.), 2/ si je pr juste pour corriger trois fautes d'orthographe, je ne vais pas devenir auteur du cours pour autant)

+0 -0

dab > On peut toujours faire correspondre le pseudo / l'email, mais c'est vrai que c'est limité. Et ensuite faire jouer une sorte de pro-rata (type < 20% pour qqs auteurs, ce sont des contribs mineures) dessus…

Quantiquement votre. Extension de tests d’API via Behat (PHP) : Behapi

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte