Есть ли хорошая графическая библиотека? На мой взгляд, это можно отрендерить и кэшировать на стороне сервера.

Какой-либо прогресс?

было бы неплохо иметь 🎉

Я бы хотел начать работать над этой фичей, если ею еще никто не занимается (ага @lafriks , я усвоил урок, +1 неконструктивно 😉).

Мне, вероятно, время от времени потребуется помощь, например, в том, как принять решение о рендеринге на стороне сервера или на стороне клиента, какую библиотеку диаграмм использовать и т. д.
Я также в основном не знаю никакого Go, но у меня хорошие знания фронтенда, так что это должно работать, и все происходит в первый раз, также я некоторое время назад хотел погрузиться в хакерство на Gitea 😄

Начнем с разбора существующих решений для определения необходимых данных и возможной структуры данных.

Гитхаб

Конечная точка API для данных вкладов: https://github.com/<owner>/<repo>/graphs/contributors-data .

Возвращенные данные JSON в основном представляют собой список объектов (каждый из которых представляет одного участника), отсортированных сначала с наименьшими вкладами, а последними с наибольшими вкладами:

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

Структура примерно аналогична описанной здесь и выглядит так:

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

Каждый член построенного массива "weeks" имеет следующие атрибуты:

• w — начало недели в виде метки времени Unix.
• a - Количество дополнений
• d - Количество удалений
• c - Количество коммитов

Вся эта информация используется для создания этих карт:

Очевидно, что график больших вкладов можно построить, сложив статистику каждого пользователя за неделю n ( 0 <= n <= weeks since the repo exists ) и нанеся кумулятивное значение для каждой недели.

GitLab

GitLab CE — с открытым исходным кодом, поэтому у нас есть соответствующие файлы:

• 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: https://gitlab.com/<owner>/<repo>/graphs/master?format=json .

Возвращаемые данные JSON намного проще:

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

Каждый член массива представляет одну фиксацию, отсортированную последней фиксации первой, исходной фиксации последней. Структура выглядит следующим образом:

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

Если пользователь сделал несколько коммитов в один и тот же день, будут просто повторяющиеся записи с одинаковой информацией о пользователе и датой, по одной для каждого коммита.

Плитки для каждого пользователя будут содержать меньше информации, чем на GitHub, построение графика выполняется по количеству коммитов за один день, по оси X — время, по оси Y — количество коммитов. Это делается как для всего репо (игнорируя имя пользователя), так и для каждого пользователя (принимая все записи фиксации для определенного пользователя в определенный день).

В обоих случаях рендеринг выполняется на стороне клиента, что дает большое преимущество в возможности построения динамических диаграмм с масштабированием.

Если это работает с вашим общим рабочим процессом здесь, я был бы в порядке, если бы меня назначили на эту проблему.

Еще несколько мыслей по этому поводу. Конструктивная обратная связь, конечно же, приветствуется!

Размещение ссылки на страницу в пользовательском интерфейсе

Это должно работать нормально, пока не нужно ничего реструктурировать.

Говоря о ссылках, страница, вероятно, должна жить в https://git.example.com/<owner>/<repo>/contributors , так работают все остальные ссылки.

Другая идея, которую я не предпочитаю , заключается в размещении графика участников на странице «Активность».

Я немного отредактировал DOM:

Я выбрал octicon-organization в качестве значка, octicon-graph тоже может подойти.

Теперь небольшое редактирование CSS на диаграмме участников GitHub для Gitea и объединение изображений:

Это очень приблизительное представление о том, как это может выглядеть, не принимая во внимание индивидуальные диаграммы для каждого пользователя.

Замечательно выглядит ^-^

@linusg отлично! Вперед, продолжать!

@lunny Я сейчас немного запутался: кто такой @Morlinest и какую роль он будет играть в этом вопросе?

Вероятно, это ошибка или у него есть какие-то тайные планы на меня :D

@linusg @Morlinest :( извините. Ошибка, подобная тому, что сказал @Morlinest . Я хочу поручить эту проблему @linusg, но обнаружил, что ее нельзя поручить тем, кто не сопровождает, и выпустить постер.

Ок, спасибо за разъяснения :smile:

О, так что я должен сделать это сейчас :D

Краткая информация для интересующихся: я хотел поработать над этим во время рождественских каникул, но не нашел много времени. Я создал базовые вещи (страницу, маршрутизацию и т. д.) и планирую продолжить работу над этим!

Большое спасибо ^-^

Хорошо, ребята, еще одно обновление. Мне удалось добраться до этого состояния:

Нажмите, чтобы развернуть:

 


Подробности:

• Данные не передаются через HTTP API, графики отображаются в формате SVG (с использованием https://github.com/wcharczuk/go-chart) на сервере. Это действительно эффективно и упрощает задачу.
• Сортировка по количеству коммитов, добавлений и удалений
• Пользовательский интерфейс «слегка» основан на GitHub 😄

Остались вопросы:

• Участники, которых нет в базе данных gitea (например, из-за того, что репозиторий был импортирован), не будут отображаться. ✅
• Проблемы с производительностью при больших репозиториях. Может быть, я просто голанг n00b.
• Удаление элементов AM/PM с оси X (можно легко сделать с помощью пользовательского форматтера ) ✅
• Исправьте масштаб оси Y пользовательских графиков, 1 фиксация должна быть вдвое меньше, чем 2 фиксации ✅
• Надлежащая поддержка темной темы (CSS выше был изменен в инструментах разработчика) ✅

Возможные улучшения:

• Статистика предназначена для ветки master (жестко закодирована), ее можно легко изменить и представить как элемент управления пользовательского интерфейса.

Идеи по изменениям и улучшениям приветствуются - я пока в восторге! Однако я опасаюсь предстоящего обзора кода :smile:

Ну... поехали! Теперь пришло время для внешнего ввода, поэтому, пожалуйста, смотрите изображения ниже.

(репозиторий gitea взят с GitHub)

Позволь мне объяснить:

• Будут показаны пользователи, которых нет в БД пользователей gitea, но без ссылки на профиль, абл. Статистика рассчитывается по имени пользователя (доступно только «имя» и «электронная почта» для каждого коммита), поэтому в GitHub есть «Неизвестно», «Неизвестно» и «无闻» против только «Неизвестно»: информация, что это все равно пользователь теряется при клонировании/импорте репо. Я думаю, это лучший вариант из доступных, мысли?

• GitHub собирает статистику за неделю, я выбрал ежедневную статистику. Следует ли это изменить?

  Вот почему ось Y на GitHub заканчивается примерно на 150 [коммитах в неделю], а на Gitea — на 52 [коммитах в день]. Также это приводит к тому, что диаграмма на Gitea появляется с большим количеством «шипов». (интерполяция также недоступна)

• GitHub исключает коммиты слияния из статистики, я ничего подобного не реализовывал (и не знаю, насколько сложно будет отличить коммит от обычного). Хотим ли мы эту функцию?

• Хотите ли вы отдельный цвет для пользовательских диаграмм?

• Как вы думаете, что еще можно улучшить?

Представление:

Я исправил все проблемы, отмеченные в моем последнем посте, и вернулся к некоторым проблемам с производительностью. Вся статистика с моей машины разработчика:

Страница участников репозитория блога Gitea загружается 1,1 с, что, вероятно, нормально (_Страница: 1090 мс Шаблон: 7 мс_)

Один для основного репозитория gitea занял 1 минуту 14 секунд и сообщает _Page: 74443ms Template: 47ms_. Тем не менее, у него девять лет истории и почти 7 тысяч коммитов.

Возможные улучшения: страница участника репозитория gitea заканчивается 602 карточками пользователей, я полагаю, что GitHub обрывается на 100. См . https://github.com/go-gitea/gitea/graphs/contributors.

Что ты об этом думаешь?

Поскольку вся история коммитов будет просматриваться каждый раз при посещении страницы, мы, вероятно, также можем улучшить ситуацию, кэшируя статистику. Не знаю, имеет ли это смысл и как будет выглядеть реализация.

Мне пришлось очистить кеш ServiceWorker, чтобы отображались измененные файлы CSS (обычное обновление кеша не работало). Что я должен сделать здесь, чтобы он работал OOTB?

  

@linusg Отличная работа!!! Как насчет того, чтобы позволить работать как cronjob, когда репозиторий большой (т.е. более 1000 коммитов)? Он может работать один или несколько дней в зависимости от конфигурации. Я думаю, что топ-100 достаточно, в противном случае лучше пагинация.

@linusg

• Статистика предназначена для ветки master (жестко закодирована), ее можно легко изменить и представить как элемент управления пользовательского интерфейса.

Возможно, вы можете использовать параметр ветки по умолчанию вместо создания другого параметра.

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время с ней не было никаких действий. Он будет закрыт, если в течение следующих 2 недель не будет никакой активности. Спасибо за ваш вклад.

Нет, все еще работаю над этим — кто-нибудь может убрать метку stale !

Нет, еще работаю над этим

Это хорошая новость, надеемся увидеть эту функцию в ближайшее время!
Раздутый, чтобы видеть диаграммы и графическое представление данных везде...

Это хорошая новость, надеемся увидеть эту функцию в ближайшее время!

Скоро :тм:

Время определенно является проблемой для меня... по сравнению с моим практически несуществующим знанием голанга, ха-ха.

Я рад видеть весь этот ажиотаж (я тоже взволнован, иначе я бы не стал над этим работать!), но если вы, ребята, чувствуете, что прогресс идет недостаточно быстро (черт возьми, прошло уже больше полугода), Я могу сделать PR со всеми изменениями и кто-то еще может помочь?

Скоро ™️

😅

но если вы, ребята, чувствуете, что прогресс идет недостаточно быстро

Неааа... кому какое дело до времени, которое вы тратите на фичу, если она очень хорошая и рабочая фича?

Я могу сделать PR со всеми изменениями и кто-то еще может помочь?

IDK, может быть, вы можете опубликовать свое репо публично здесь, на GH, чтобы другие люди могли пиарить ваше репо и заставить его работать, чтобы вы могли пиарить официальное и интегрировать его.
ИЛИ вы можете открыть PR для новой ветки в официальном репо, из которого опытные и желающие времени люди могут разветвляться и работать, и вместо этого PR, ожидая, пока ветка будет объединена с мастером, конечно...

@linusg Пожалуйста, отправьте PR, что, возможно, кто-то может помочь вам, когда вас нет.

с нетерпением жду этой функции. Это устарело сейчас? .....Спасибо

Есть ли еще новости здесь?

Были ли когда-либо представлены здесь PR или ветки?

Думаю, нет. @linusg

Я не думаю, что когда-либо продвигал свои изменения. Даже не уверен, есть ли они у меня - извините!