¿Hay un buen gráfico-lib? En mi opinión, esto se puede representar y almacenar en caché del lado del servidor

¿Cualquier progreso?

Sería bueno tener 🎉

Me gustaría comenzar a trabajar en esta característica, si nadie ya lo está (sí, @lafriks , aprendí mi lección, +1 no es constructivo 😉).

Probablemente necesitaría ayuda de vez en cuando, por ejemplo, sobre cómo decidir sobre la representación del lado del servidor o del cliente, qué biblioteca de gráficos usar, etc.
Básicamente, tampoco conozco ningún Go, pero tengo un buen conocimiento de la interfaz, por lo que debería funcionar, y todo tiene una primera vez, también quería sumergirme en la piratería de Gitea hace un tiempo 😄

Comencemos por desarmar las soluciones existentes para identificar los datos necesarios y la posible estructura de datos.

GitHub

El punto final de la API para los datos de contribuciones es https://github.com/<owner>/<repo>/graphs/contributors-data .

Los datos JSON devueltos son básicamente una lista de objetos (cada uno de los cuales representa a un colaborador) ordenados con menos contribuciones primero, la mayoría de las contribuciones al final:

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

La estructura es más o menos similar a la documentada aquí y se ve así:

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

Cada miembro de la matriz "weeks" que se construye tiene los siguientes atributos:

• w - Comienzo de la semana, dado como una marca de tiempo de Unix.
• a - Número de adiciones
• d - Número de eliminaciones
• c - Número de confirmaciones

Toda esa información se utiliza para construir estas tarjetas:

El gráfico de grandes contribuciones obviamente se puede construir sumando las estadísticas de cada usuario de una semana n ( 0 <= n <= weeks since the repo exists ) y trazando el valor acumulativo para cada semana.

GitLab

GitLab CE es de código abierto, por lo que tenemos los archivos relevantes:

• 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

El punto final de la API es https://gitlab.com/<owner>/<repo>/graphs/master?format=json .

Los datos JSON devueltos son mucho más simples:

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

Cada miembro de la matriz representa una confirmación, la última confirmación ordenada primero, la confirmación inicial en último lugar. La estructura queda de la siguiente manera:

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

Si un usuario realizó varias confirmaciones el mismo día, simplemente habrá entradas duplicadas con la misma información de usuario y fecha, una para cada confirmación.

Los mosaicos por usuario contendrán menos información que en GitHub, el trazado se realiza tomando la cantidad de confirmaciones para un día, el eje X es el tiempo, el eje Y es la cantidad de confirmaciones. Eso se hace tanto para todo el repositorio (ignorando el nombre de usuario) como para cada usuario (tomando todas las entradas de confirmación para un usuario específico en un día específico).

En ambos casos, el renderizado se realiza del lado del cliente, lo que tiene la gran ventaja de poder construir gráficos dinámicos con zoom.

Si funciona con su flujo de trabajo general aquí, estaría bien si me asignaran a este problema.

Algunas reflexiones más sobre esto. ¡Los comentarios constructivos son, por supuesto, muy apreciados!

Colocar el enlace de la página en la interfaz de usuario

Eso debería funcionar bien, no hay necesidad de reestructurar nada por ahora.

Hablando de enlaces, la página probablemente debería vivir en https://git.example.com/<owner>/<repo>/contributors , así es como funcionan todos los demás enlaces.

Otra idea, que no prefiero , es colocar los gráficos de los contribuyentes en la página Actividad.

Hice algo de edición de DOM:

Elegí octicon-organization como ícono, octicon-graph también podría funcionar.

Ahora un poco de edición rápida de CSS en la tabla de colaboradores de GitHub para Gitea y la fusión de las imágenes:

Esa es una idea muy aproximada de cómo puede verse, sin tener en cuenta los gráficos individuales por usuario.

Se ve maravilloso ^-^

@linusg genial! ¡Avanzar!

@lunny Estoy un poco confundido en este momento: ¿Quién es @Morlinest y qué papel jugará en este problema?

Probablemente sea un error o tal vez tenga algunos planes secretos conmigo :D

@linusg @Morlinest :( lo siento. Un error como lo que dijo @Morlinest . Quiero asignar este problema a @linusg pero descubrí que no se puede asignar a los que no son mantenedores y publicar el problema.

Ok, gracias por la aclaración :smile:

Oh, tendré que hacerlo ahora :D

Aviso breve para los interesados: quería trabajar en esto durante las vacaciones de Navidad, pero no pude encontrar mucho tiempo. ¡He creado las cosas básicas (página, enrutamiento, etc.) y planeo continuar trabajando en ello!

Muchas gracias ^-^

Ok amigos, otra actualización más. Logré llegar a este estado:

Haga clic para ampliar:

 


Detalles:

• No hay datos expuestos a través de la API HTTP, los gráficos se representan en SVG (usando https://github.com/wcharczuk/go-chart) en el servidor. Esto es realmente eficaz y mantiene las cosas simples.
• Clasificación por número de confirmaciones, adiciones y eliminaciones
• La interfaz de usuario está "ligeramente" basada en GitHub 😄

Problemas restantes:

• Los colaboradores que no están en la base de datos de gitea (por ejemplo, porque el repositorio fue importado) no aparecerán. ✅
• Problemas de rendimiento con repositorios más grandes. Podría ser solo yo siendo un golang n00b.
• Eliminar las cosas AM/PM del eje X (se puede hacer fácilmente a través de un formateador personalizado ) ✅
• Corrija la escala del eje Y de los gráficos de usuario, 1 confirmación debe tener la mitad de la altura que 2 confirmaciones ✅
• Compatibilidad adecuada con el tema oscuro (el CSS de arriba se modificó en las herramientas de desarrollo) ✅

Posibles mejoras:

• Las estadísticas son para la rama maestra (codificada), esto se puede cambiar fácilmente y exponer como un control de interfaz de usuario

Se aceptan ideas para cambios y mejoras . ¡Hasta ahora estoy entusiasmado! Sin embargo, temo la próxima revisión del código :smile:

Así que... ¡aquí vamos! Ahora es el momento de alguna entrada externa, así que vea las imágenes a continuación.

(gitea repositorio tomado de GitHub)

Dejame explicar:

• Se mostrarán los usuarios que no estén en la BBDD de usuarios de gitea, pero sin enlace al perfil, obv. Las estadísticas se calculan por nombre de usuario (disponible solo "nombre" y "correo electrónico" por cada confirmación), es por eso que hay "Desconocido", "Desconocido" y "无闻" frente a solo "Desconocido" en GitHub: La información, que esto es todo el mismo usuario se pierde al clonar/importar el repositorio. Supongo que esa es la mejor opción disponible, ¿pensamientos?

• GitHub compila estadísticas por semana, fui con estadísticas diarias. ¿Debería cambiarse esto?

  Esa es la razón por la que el eje Y en GitHub termina en ~150 [commits por semana] y el de Gitea en 52 [commits por día]. También hace que el gráfico de Gitea aparezca con más "picos". (la interpolación tampoco está disponible)

• GitHub excluye las confirmaciones de combinación de las estadísticas, no implementé nada de este tipo (y no sé lo difícil que sería distinguir una de una confirmación normal). ¿Queremos esta función?

• ¿Desea un color separado para los gráficos por usuario?

• ¿Qué más crees que se puede mejorar?

Rendimiento:

Solucioné todos los problemas señalados en mi última publicación y volví a algunos problemas de rendimiento. Todas las estadísticas de mi máquina de desarrollo:

La página de colaboradores del repositorio del blog de Gitea tarda 1,1 segundos en cargarse, lo que probablemente esté bien (_Página: 1090ms Plantilla: 7ms_)

El del repositorio principal de gitea tomó 1min 14s e informa _Página: 74443ms Plantilla: 47ms_. Sin embargo, tiene nueve años de historia y casi 7k confirmaciones.

Posibles mejoras: la página de contribuyentes del repositorio de gitea termina con 602 tarjetas de usuario, creo que GitHub se corta en 100. Consulte https://github.com/go-gitea/gitea/graphs/contributors.

¿Qué piensas sobre eso?

Dado que todo el historial de confirmaciones se recorrerá cada vez que se visite la página, probablemente también podamos mejorar la situación almacenando en caché las estadísticas. No tengo idea si eso tiene sentido y cómo sería la implementación.

Tuve que borrar el caché de ServiceWorker para que aparecieran los archivos CSS modificados (la actualización normal del caché no funcionaría). ¿Qué tengo que hacer aquí para que funcione OOTB?

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

@linusg Gran trabajo!!! ¿Qué tal dejar que el trabajo funcione como un cronjob cuando el repositorio es grande (es decir, más de 1000 confirmaciones)? Se puede ejecutar uno o más días según la configuración. Creo que el top 100 es suficiente, de lo contrario, la paginación es mejor.

@linusg

• Las estadísticas son para la rama maestra (codificada), esto se puede cambiar fácilmente y exponer como un control de interfaz de usuario

Tal vez pueda usar la opción de rama predeterminada en lugar de crear otra opción.

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad durante las próximas 2 semanas. Gracias por sus aportaciones.

No, todavía estoy trabajando en esto: ¡alguien podría eliminar la etiqueta stale !

No, todavía estoy trabajando en esto.

Esas son buenas noticias, ¡esperamos ver esta función pronto!
Emocionado de ver gráficos y representaciones de datos gráficos en todas partes...

Esas son buenas noticias, ¡esperamos ver esta función pronto!

Pronto :tm:

El tiempo es definitivamente un problema para mí... al lado de mi conocimiento básicamente inexistente de golang, jaja.

Estoy feliz de ver toda la emoción (¡yo también estoy emocionada, no trabajaría en esto de otra manera!), pero si ustedes sienten que esto no está progresando lo suficientemente rápido (maldita sea, ha pasado más de medio año), ¿Puedo hacer un PR con todos los cambios y alguien más puede ayudar?

Pronto ™️

😅

pero si ustedes sienten que esto no está progresando lo suficientemente rápido

Naaah... ¿a quién le importa el tiempo que dedicas a una función, si es una función muy buena y funcional?

¿Puedo hacer un PR con todos los cambios y alguien más puede ayudar?

IDK, tal vez puedas publicar tu repositorio públicamente aquí en GH para que otras personas puedan promocionar tu repositorio y hacer que funcione para que puedas publicar el oficial e integrarlo.
O puede abrir un PR para una nueva sucursal en el repositorio oficial desde el cual las personas capacitadas y dispuestas al tiempo pueden bifurcarse y trabajar y PR que, en cambio, espera que la sucursal se fusione con el maestro, por supuesto ...

@linusg Envíe un PR para que alguien pueda ayudarlo cuando esté ausente.

esperando esta función. ¿Está rancio ahora? .....Gracias

¿Alguna noticia más por aquí?

¿Alguna vez se envió aquí un PR o una sucursal?

Yo creo que no. @linusg

Creo que nunca presioné mis cambios. Ni siquiera estoy seguro de si todavía los tengo, ¡lo siento!