Existe-t-il un bon graph-lib? À mon avis, cela peut être rendu et mis en cache côté serveur

Aucun progrès?

serait bien d'avoir 🎉

J'aimerais commencer à travailler sur cette fonctionnalité, si personne n'y est déjà (oui @lafriks , j'ai retenu la leçon, +1 n'est pas constructif 😉).

J'aurais probablement besoin d'aide de temps en temps, par exemple sur la façon de décider du rendu côté serveur ou client, de la bibliothèque de graphiques à utiliser, etc.
Je ne connais pas non plus de Go mais j'ai de bonnes connaissances en frontend donc ça devrait marcher, et tout a une première fois, aussi je voulais plonger dans le piratage sur Gitea il y a quelque temps 😄

Commençons par démonter les solutions existantes pour identifier les données requises et la structure de données possible.

GitHub

Le point de terminaison de l'API pour les données de contribution est https://github.com/<owner>/<repo>/graphs/contributors-data .

Les données JSON renvoyées sont essentiellement une liste d'objets (chacun représentant un contributeur) triés les moins de contributions en premier, la plupart des contributions en dernier :

[
  { ... }, // User with least contributions
    ...
  { ... }, // User with second most contributions
  { ... }  // User with most contributions
]

La structure est à peu près similaire à celle documentée ici et ressemble à ceci :

{
  "author": {
    "id": 12345,
    "login": "octocat",
    "avatar": "https://avatars3.githubusercontent.com/u/12345?s=60&v=4",
    "path": "/octocat",
    "hovercard_url": "/hovercards?user_id=12345"
  },
  "total": 123,
  "weeks": [
    // First week in which the repo existed
    {
      "w": 1391904000,
      "a": 6898,
      "d": 77,
      "c": 10
    },
    // Second week in which the repo existed
    {
      "w": 1392508800,
      "a": 2437,
      "d": 439,
      "c": 6
    },
    ...
    // Current week
    {
      "w": 1538265600,
      "a": 0,
      "d": 0,
      "c": 0
    }
  ]
}

Chaque membre du tableau "weeks" est construit avec les attributs suivants :

• w - Début de la semaine, donné sous la forme d'un horodatage Unix.
• a - Nombre d'ajouts
• d - Nombre de suppressions
• c - Nombre de commits

Toutes ces informations sont utilisées pour créer ces cartes :

Le graphique des grandes contributions peut évidemment être construit en additionnant les statistiques de chaque utilisateur d'une semaine n ( 0 <= n <= weeks since the repo exists ) et en traçant la valeur cumulée pour chaque semaine.

GitLab

GitLab CE est Open Source, nous avons donc les fichiers pertinents :

• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/controllers/projects/graphs_controller.rb
• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/graphs/commits.rb
• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/views/projects/graphs/show.html.haml
• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/stylesheets/pages/graph.scss
• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/vue_shared/components/bar_chart.vue

Le point de terminaison de l'API est https://gitlab.com/<owner>/<repo>/graphs/master?format=json .

Les données JSON renvoyées sont beaucoup plus simples :

[
  { ... }, // Latest commit
  { ... }, // Second latest commit
    ...
  { ... }, // First commit
]

Chaque membre du tableau représente un commit, le dernier commit trié en premier, le commit initial en dernier. La structure se présente comme suit :

{
  "author_name": "Some User",
  "author_email": "[email protected]",
  "date": "2018-10-02"
}

Si un utilisateur a effectué plusieurs validations le même jour, il y aura simplement des entrées en double avec les mêmes informations utilisateur et date, une pour chaque validation.

Les tuiles par utilisateur contiendront moins d'informations que sur GitHub, le tracé se fait en prenant le nombre de commits pour une journée, l'axe X est le temps, l'axe Y le nombre de commits. Cela est fait à la fois pour l'ensemble du référentiel (en ignorant le nom d'utilisateur) et pour chaque utilisateur (en prenant toutes les entrées de validation pour un utilisateur spécifique à un jour spécifique).

Dans les deux cas le rendu se fait côté client, ce qui a le grand avantage de pouvoir construire des graphiques dynamiques avec zoom.

Si cela fonctionne avec votre flux de travail général ici, je serais d'accord pour être affecté à ce problème.

Quelques réflexions supplémentaires à ce sujet. Les commentaires constructifs sont bien sûr très appréciés!

Placer le lien de la page sur l'interface utilisateur

Cela devrait bien fonctionner, pas besoin de restructurer quoi que ce soit pour l'instant.

En parlant de liens, la page devrait probablement vivre à https://git.example.com/<owner>/<repo>/contributors , c'est ainsi que fonctionnent tous les autres liens.

Une autre idée, que je ne préfère pas , est de mettre le(s) graphique(s) des contributeurs sur la page Activité.

J'ai fait quelques modifications DOM:

J'ai choisi octicon-organization comme icône, octicon-graph pourrait aussi fonctionner.

Maintenant, quelques modifications CSS rapides sur le graphique des contributeurs GitHub pour Gitea et la fusion des images :

C'est une idée très approximative de ce à quoi cela peut ressembler, sans tenir compte des graphiques individuels par utilisateur.

Il a l'air magnifique ^-^

@linusg génial ! Vas-y!

@lunny Je suis un peu confus en ce moment : qui est @Morlinest et quel rôle jouera-t-il dans ce numéro ?

C'est probablement une erreur ou peut-être qu'il a des plans secrets avec moi :D

@linusg @Morlinest :( désolé. Une erreur comme ce que @Morlinest a dit. Je veux attribuer ce problème à @linusg mais j'ai trouvé qu'il ne peut pas être attribué aux non-responsables et à l'affiche du problème.

Ok merci pour la précision :smile:

Oh, alors je vais devoir le faire maintenant :D

Petite info pour ceux que ça intéresse : je voulais travailler dessus pendant les vacances de Noël, mais je n'ai pas trouvé beaucoup de temps. J'ai créé les éléments de base (page, routage, etc.) et je prévois de continuer à travailler dessus !

Merci beaucoup ^-^

Ok les gens, encore une autre mise à jour. J'ai réussi à arriver à cet état:

Cliquez pour agrandir:

 


Des détails:

• Aucune donnée exposée sur l'API HTTP, les graphiques sont rendus en SVG (en utilisant https://github.com/wcharczuk/go-chart) sur le serveur. C'est vraiment performant et cela simplifie les choses.
• Tri par nombre de commits, ajouts et suppressions
• L'UI est "légèrement" basée sur GitHub 😄

Problèmes restants :

• Les contributeurs qui ne sont pas dans la base de données gitea (par exemple parce que le référentiel a été importé) ne s'afficheront pas. ✅
• Problèmes de performances avec des référentiels plus volumineux. Peut-être juste moi étant un golang n00b.
• Supprimer les éléments AM / PM de l'axe X (peut être facilement effectué via un formateur personnalisé ) ✅
• Corrigez l'échelle de l'axe Y des graphiques utilisateur, 1 commit doit être la moitié de la hauteur de 2 commits ✅
• Prise en charge appropriée du thème sombre (le CSS ci-dessus a été modifié dans les outils de développement) ✅

Améliorations possibles :

• Les statistiques sont pour la branche principale (codée en dur), cela peut être facilement modifié et exposé en tant que contrôle de l'interface utilisateur

Les idées de changements et d'améliorations sont les bienvenues - je suis sorti jusqu'à présent ! J'ai peur de la revue de code à venir :smile:

Sooo... c'est parti ! Il est maintenant temps pour une entrée externe, alors veuillez voir ci-dessous les images.

(dépôt gitea extrait de GitHub)

Laisse-moi expliquer:

• Les utilisateurs qui ne sont pas dans la base de données des utilisateurs de gitea seront affichés, mais sans lien vers le profil, obv. Les statistiques sont calculées par nom d'utilisateur (disponibles uniquement "nom" et "email" pour chaque commit), c'est pourquoi il y a "Inconnu", "Inconnu" et "无闻" contre uniquement "Inconnu" dans GitHub : tout le même utilisateur est perdu lors du clonage/importation du référentiel. Je suppose que c'est la meilleure option disponible, des pensées?

• GitHub compile des statistiques par semaine, je suis allé avec des statistiques quotidiennes. Cela devrait-il être changé?

  C'est la raison pour laquelle l'axe Y sur GitHub se termine à ~150 [commits per week] et celui de Gitea à 52 [commits per day]. De plus, cela fait apparaître le graphique sur Gitea avec plus de "pics". (l'interpolation n'est pas disponible également)

• GitHub exclut les commits de fusion des statistiques, je n'ai rien implémenté de ce genre (et je ne sais pas à quel point il serait difficile d'en distinguer un d'un commit normal). Voulons-nous cette fonctionnalité ?

• Souhaitez-vous une couleur distincte pour les graphiques par utilisateur ?

• Selon vous, qu'est-ce qui peut encore être amélioré ?

Performance:

J'ai corrigé tous les problèmes notés dans mon dernier message et je reviens à certains problèmes de performances. Toutes les statistiques de ma machine de développement :

La page des contributeurs du dépôt du blog Gitea prend 1,1 s à charger, ce qui est probablement correct (_Page : 1090 ms Modèle : 7 ms_)

Celui pour le repo principal de gitea a pris 1min 14s et rapporte _Page : 74443ms Modèle : 47ms_. Cependant, il a neuf ans d'histoire et près de 7 000 commits.

Améliorations possibles : la page des contributeurs de gitea repo se termine avec 602 cartes d'utilisateurs, je crois que GitHub en coupe à 100. Voir https://github.com/go-gitea/gitea/graphs/contributors.

Qu'est ce que tu penses de ça?

Étant donné que l'intégralité de l'historique des commits sera parcourue à chaque visite de la page, nous pouvons probablement aussi améliorer la situation en mettant en cache les statistiques. Aucune idée si cela a du sens et à quoi ressemblerait la mise en œuvre.

J'ai dû vider le cache de ServiceWorker pour que les fichiers CSS modifiés s'affichent (l'actualisation normale du cache ne fonctionnerait pas). Que dois-je faire ici pour que cela fonctionne OOTB ?

   ! [image](https://user-images.githubusercontent.com/19366641/50846507-9b575400-136f-11e9-9a6f-97f7a9ec28a1.png)

@linusg Excellent travail !!! Que diriez-vous de laisser le travail en tant que tâche cron lorsque le référentiel est volumineux (c'est-à-dire plus de 1000 commits) ? Il peut être exécuté un ou plusieurs jours selon la configuration. Je pense que le top 100 est suffisant, sinon la pagination est meilleure.

@linusg

• Les statistiques sont pour la branche principale (codée en dur), cela peut être facilement modifié et exposé en tant que contrôle de l'interface utilisateur

Vous pouvez peut-être utiliser l'option de branche par défaut au lieu de créer une autre option.

Ce problème a été automatiquement marqué comme obsolète, car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité n'a lieu au cours des 2 prochaines semaines. Merci pour vos contributions.

Non, je travaille toujours dessus - quelqu'un pourrait supprimer l'étiquette stale !

Non, je travaille toujours dessus

C'est une bonne nouvelle, en espérant voir cette fonctionnalité arriver bientôt !
Hâte de voir des graphiques et des représentations graphiques de données partout...

C'est une bonne nouvelle, en espérant voir cette fonctionnalité arriver bientôt !

Bientôt :tm:

Le temps est définitivement un problème pour moi... à côté de ma connaissance quasi inexistante du golang, haha.

Je suis heureux de voir toute l'excitation (je suis excité aussi, je ne travaillerais pas là-dessus autrement !), mais si vous avez l'impression que cela ne progresse pas assez vite (putain, ça fait plus de six mois), Je peux faire un PR avec tous les changements et quelqu'un d'autre peut m'aider ?

Bientôt ™️

😅

mais si vous avez l'impression que cela ne progresse pas assez vite

Naaah .. peu importe le temps que vous prenez pour une fonctionnalité, si c'est une très bonne fonctionnalité et qui fonctionne ?

Je peux faire un PR avec tous les changements et quelqu'un d'autre peut m'aider ?

IDK, peut-être que vous pouvez publier votre dépôt publiquement ici sur GH afin que d'autres personnes puissent PR votre dépôt et le faire fonctionner afin que vous puissiez PR l'officiel et l'intégrer
OU vous pouvez ouvrir un PR pour une nouvelle branche sur le repo officiel à partir duquel des personnes qualifiées et désireuses de temps peuvent bifurquer et travailler et PR qui à la place, en attendant que la branche soit fusionnée en master bien sûr...

@linusg Veuillez envoyer un PR que quelqu'un pourrait peut-être vous aider lorsque vous êtes absent.

dans l'attente de cette fonctionnalité. Est-il obsolète maintenant ? .....Merci

D'autres nouvelles ici?

Un PR ou une succursale a-t-il déjà été soumis ici ?

Je crois que non. @linusg

Je ne pense pas avoir jamais poussé mes changements. Je ne sais même pas si je les ai encore - désolé !