Gibt es eine gute Graph-Lib? Meiner Meinung nach kann dies serverseitig gerendert und zwischengespeichert werden

Irgendein Fortschritt?

wäre schön zu haben 🎉

Ich würde gerne anfangen, an diesem Feature zu arbeiten, wenn noch niemand daran arbeitet (yeah @lafriks , ich habe meine Lektion gelernt, +1 ist nicht konstruktiv 😉).

Ich würde wahrscheinlich hin und wieder etwas Hilfe brauchen, z. B. bei der Entscheidung über server- oder clientseitiges Rendern, welche Diagrammbibliothek verwendet werden soll usw.
Ich kenne auch im Grunde kein Go, habe aber gute Frontend-Kenntnisse, also sollte es funktionieren, und alles hat ein erstes Mal, außerdem wollte ich vor einiger Zeit in das Hacken auf Gitea eintauchen 😄

Beginnen wir damit, vorhandene Lösungen zu zerlegen, um erforderliche Daten und mögliche Datenstrukturen zu identifizieren.

GitHub

API-Endpunkt für Beitragsdaten ist https://github.com/<owner>/<repo>/graphs/contributors-data .

Die zurückgegebenen JSON-Daten sind im Grunde eine Liste von Objekten (die jeweils einen Mitwirkenden darstellen), sortiert nach den wenigsten Beiträgen zuerst und den meisten Beiträgen zuletzt:

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

Der Aufbau ähnelt in etwa dem hier dokumentierten und sieht folgendermaßen aus:

{
  "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
    }
  ]
}

Jedes Mitglied des Arrays "weeks" hat die folgenden Attribute:

• w - Beginn der Woche, angegeben als Unix-Zeitstempel.
• a - Anzahl der Hinzufügungen
• d - Anzahl der Löschungen
• c - Anzahl der Commits

All diese Informationen werden verwendet, um diese Karten zu erstellen:

Das Diagramm der großen Beiträge kann natürlich erstellt werden, indem die Statistiken von jedem Benutzer einer Woche n ( 0 <= n <= weeks since the repo exists ) addiert und der kumulative Wert für jede Woche aufgetragen wird.

GitLab

GitLab CE ist Open Source, daher haben wir die relevanten Dateien:

• 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

API-Endpunkt ist https://gitlab.com/<owner>/<repo>/graphs/master?format=json .

Die zurückgegebenen JSON-Daten sind viel einfacher:

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

Jedes Mitglied des Arrays stellt einen Commit dar, sortiert nach dem letzten Commit zuerst und dem ersten Commit zuletzt. Der Aufbau sieht wie folgt aus:

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

Wenn ein Benutzer am selben Tag mehrere Commits durchgeführt hat, gibt es einfach doppelte Einträge mit denselben Benutzerinformationen und demselben Datum, einen für jeden Commit.

Die Kacheln pro Benutzer enthalten weniger Informationen als auf GitHub, die Darstellung erfolgt anhand der Anzahl der Commits für einen Tag, die X-Achse ist die Zeit, die Y-Achse die Anzahl der Commits. Dies wird sowohl für das gesamte Repo (unter Berücksichtigung des Benutzernamens) als auch für jeden Benutzer (alle Commit-Einträge für einen bestimmten Benutzer an einem bestimmten Tag) durchgeführt.

In beiden Fällen erfolgt das Rendern clientseitig, was den großen Vorteil hat, dynamische Diagramme mit Zoomen erstellen zu können.

Wenn es mit Ihrem allgemeinen Arbeitsablauf hier funktioniert, wäre es in Ordnung, wenn ich diesem Problem zugewiesen werde.

Noch ein paar Gedanken dazu. Konstruktives Feedback ist natürlich sehr willkommen!

Platzieren des Seitenlinks auf der Benutzeroberfläche

Das sollte gut funktionieren, keine Notwendigkeit, etwas umzustrukturieren.

Apropos Links, die Seite sollte wahrscheinlich bei https://git.example.com/<owner>/<repo>/contributors wohnen, so funktionieren alle anderen Links da oben.

Eine andere Idee, die ich nicht bevorzuge , ist das Platzieren der Beitragsgrafik(en) auf der Aktivitätsseite.

Ich habe einige DOM-Bearbeitungen durchgeführt:

Ich habe octicon-organization als Symbol gewählt, octicon-graph könnte auch funktionieren.

Jetzt einige schnelle CSS-Bearbeitungen im GitHub-Kontributor-Diagramm für Gitea und das Zusammenführen der Bilder:

Das ist eine sehr grobe Vorstellung davon, wie es aussehen könnte, ohne Berücksichtigung individueller Diagramme pro Benutzer.

Sieht wunderbar aus ^-^

@linusg toll! Fortfahren!

@lunny Ich bin gerade etwas verwirrt: Wer ist @Morlinest und welche Rolle wird er in dieser Ausgabe spielen?

Es ist wahrscheinlich ein Fehler oder vielleicht hat er geheime Pläne mit mir :D

@linusg @Morlinest :( Entschuldigung. Ein Fehler wie das, was @Morlinest gesagt hat. Ich möchte dieses Problem @linusg zuweisen, aber ich habe festgestellt, dass es nicht Nicht-Betreuern und Postern zugewiesen werden kann.

Ok danke für die Aufklärung :smile:

Oh, also muss ich es jetzt tun :D

Kurze Vorwarnung für Interessierte: Ich wollte in den Weihnachtsferien daran arbeiten, fand aber nicht viel Zeit. Ich habe die grundlegenden Dinge (Seite, Routing usw.) erstellt und plane, weiter daran zu arbeiten!

Vielen Dank ^-^

Ok Leute, noch ein Update. Ich habe es geschafft, diesen Zustand zu erreichen:

Zum erweitern klicken:

 


Einzelheiten:

• Keine Daten werden über die HTTP-API offengelegt, Grafiken werden auf dem Server in SVG gerendert (unter Verwendung von https://github.com/wcharczuk/go-chart). Das ist wirklich performant und hält die Dinge einfach.
• Sortierung nach Anzahl der Commits, Hinzufügungen und Löschungen
• Die Benutzeroberfläche basiert "leicht" auf GitHub 😄

Verbleibende Probleme:

• Mitwirkende, die nicht in der Gitea-DB sind (z. B. weil das Repo importiert wurde), werden nicht angezeigt. ✅
• Leistungsprobleme bei größeren Repositories. Vielleicht bin nur ich ein Golang n00b.
• Entfernen des AM/PM-Zeugs von der X-Achse (kann einfach über einen benutzerdefinierten Formatierer durchgeführt werden) ✅
• Korrigieren Sie die Y-Achsen-Skalierung von Benutzerdiagrammen, 1 Commit sollte halb so hoch sein wie 2 Commits ✅
• Korrekte Unterstützung für dunkle Themen (CSS für oben wurde in den Entwicklertools optimiert) ✅

Mögliche Erweiterungen:

• Statistiken sind für den Master-Zweig (fest codiert), dieser kann einfach geändert und als UI-Steuerelement verfügbar gemacht werden

Ideen für Änderungen und Verbesserungen willkommen - ich bin soweit gespannt! Ich fürchte allerdings das kommende Code-Review :smile:

Sooo ... los geht's! Jetzt ist es an der Zeit für etwas externen Input, also sehen Sie sich bitte die Bilder unten an.

(Gitea-Repo von GitHub übernommen)

Lassen Sie mich erklären:

• Benutzer, die nicht in der Gitea-Benutzerdatenbank sind, werden angezeigt, aber ohne Link zum Profil, obv. Statistiken werden nach Benutzernamen berechnet (verfügbar sind nur "name" und "email" pro Commit), deshalb gibt es "Unknown", "Unknwon" und "无闻" vs only "Unknwon" in GitHub: The information that this is derselbe Benutzer geht beim Klonen/Importieren des Repos verloren. Ich denke, das ist die beste verfügbare Option, Gedanken?

• GitHub erstellt Statistiken pro Woche, ich ging mit täglichen Statistiken. Sollte dies geändert werden?

  Aus diesem Grund endet die Y-Achse auf GitHub bei ~150 [Commits pro Woche] und die Gitea-Achse bei 52 [Commits pro Tag]. Außerdem erscheint das Diagramm auf Gitea mit mehr "Spikes". (Interpolation ist ebenfalls nicht verfügbar)

• GitHub schließt Merge-Commits aus den Statistiken aus, ich habe nichts dergleichen implementiert (und weiß nicht, wie schwer es wäre, einen von einem normalen Commit zu unterscheiden). Wollen wir diese Funktion?

• Wünschen Sie eine separate Farbe für die Diagramme pro Benutzer?

• Was kann Ihrer Meinung nach noch verbessert werden?

Leistung:

Ich habe alle Probleme behoben, die in meinem letzten Beitrag erwähnt wurden, und ich bin wieder bei einigen Leistungsproblemen. Alle Statistiken von meiner Entwicklungsmaschine:

Das Laden der Contributors-Seite des Gitea-Blog-Repos dauert 1,1 Sekunden, was wahrscheinlich in Ordnung ist (_Page: 1090ms Template: 7ms_)

Der für das Gitea-Hauptrepo dauerte 1 Minute 14 Sekunden und meldet _Seite: 74443 ms Vorlage: 47 ms_. Es hat jedoch eine neunjährige Geschichte und fast 7.000 Commits.

Mögliche Verbesserungen: Die Gitea-Repo-Contributor-Seite endet mit 602 Benutzerkarten, ich glaube, GitHub schneidet bei 100 ab. Siehe https://github.com/go-gitea/gitea/graphs/contributors.

Was denkst du darüber?

Da die gesamte Commit-Historie bei jedem Besuch der Seite durchlaufen wird, können wir die Situation wahrscheinlich auch verbessern, indem wir die Statistiken zwischenspeichern. Keine Ahnung, ob das Sinn macht und wie die Umsetzung aussehen würde.

Ich musste den Cache des ServiceWorkers löschen, damit die geänderten CSS-Dateien angezeigt werden (normale Cache-Aktualisierung würde nicht funktionieren). Was muss ich hier tun, damit es OOTB funktioniert?

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

@linusg Tolle Arbeit!!! Wie wäre es, das als Cronjob arbeiten zu lassen, wenn das Repository groß ist (dh über 1000 Commits)? Es kann je nach Konfiguration einen oder mehrere Tage ausgeführt werden. Ich denke, Top 100 ist genug, sonst ist die Paginierung besser.

@linusg

• Statistiken sind für den Master-Zweig (fest codiert), dieser kann einfach geändert und als UI-Steuerelement verfügbar gemacht werden

Vielleicht können Sie die Standardverzweigungsoption verwenden, anstatt eine andere Option zu erstellen.

Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivität gab. Es wird geschlossen, wenn in den nächsten 2 Wochen keine weiteren Aktivitäten stattfinden. Vielen Dank für Ihre Beiträge.

Nein, daran wird noch gearbeitet - jemand könnte das Label stale entfernen!

Nein, daran wird noch gearbeitet

Das sind gute Neuigkeiten, in der Hoffnung, dass diese Funktion bald verfügbar ist!
Gehyped, überall Diagramme und grafische Datendarstellungen zu sehen ...

Das sind gute Neuigkeiten, in der Hoffnung, dass diese Funktion bald verfügbar ist!

Bald :tm:

Zeit ist definitiv ein Problem für mich ... neben meinen im Grunde nicht vorhandenen Golang-Kenntnissen, haha.

Ich freue mich über die ganze Aufregung (ich bin auch aufgeregt, sonst würde ich nicht daran arbeiten!), aber wenn Sie das Gefühl haben, dass dies nicht schnell genug vorankommt (verdammt, es ist über ein halbes Jahr her), Ich kann eine PR mit allen Änderungen machen und jemand anderes kann helfen?

Bald ™️

😅

aber wenn Sie das Gefühl haben, dass dies nicht schnell genug vorankommt

Naaah.. wen interessiert die Zeit, die man sich für ein Feature nimmt, wenn es ein sehr gutes und funktionierendes Feature ist?

Ich kann eine PR mit allen Änderungen machen und jemand anderes kann helfen?

IDK, vielleicht können Sie Ihr Repo öffentlich hier auf GH posten, damit andere Leute Ihr Repo PR machen und es zum Laufen bringen können, damit Sie das offizielle Repo PR machen und es integrieren können
ODER Sie können einen PR für einen neuen Zweig im offiziellen Repo eröffnen, von dem qualifizierte und zeitwillige Leute forken und arbeiten können, und PR, die stattdessen darauf warten, dass der Zweig mit dem Master zusammengeführt wird ...

@linusg Bitte sende eine PN, dass dir vielleicht jemand helfen könnte, wenn du abwesend bist.

freue mich auf diese Funktion. Ist es jetzt altbacken? .....Danke

Gibt es hier weitere Neuigkeiten?

Wurde hier jemals eine PR oder Branche eingereicht?

Ich denke nicht. @linusg

Ich glaube nicht, dass ich jemals meine Änderungen gepusht habe. Ich bin mir nicht einmal sicher, ob ich sie noch habe - sorry!