有没有好的图库？ 在我看来，这可以在服务器端渲染和缓存

任何进展？

很高兴有🎉

我想开始研究这个功能，如果没有人使用它（是的@lafriks ，我吸取了教训， +1没有建设性😉）。

我可能时不时需要一些帮助，例如如何决定服务器或客户端渲染，使用什么图表库等。
我基本上也不会 Go，但有很好的前端知识，所以它应该可以工作，而且一切都是第一次，我前段时间也想深入研究 Gitea 的黑客攻击😄

让我们首先拆开现有的解决方案来识别所需的数据和可能的数据结构。

GitHub

贡献数据的 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 轴是提交次数。 这对整个 repo（忽略用户名）和每个用户（在特定日期获取特定用户的所有提交条目）都完成。

在这两种情况下，渲染都是在客户端完成的，这具有能够构建具有缩放功能的动态图表的巨大优势。

如果它适用于您的一般工作流程，我会很好地分配给这个问题。

对此还有一些想法。 建设性的反馈当然会受到高度赞赏！

在 UI 上放置页面链接

这应该可以正常工作，现在不需要重组任何东西。

说到链接，页面可能应该位于https://git.example.com/<owner>/<repo>/contributors ，这就是那里所有其他链接的工作方式。

另一个我不喜欢的想法是将贡献者图表放在活动页面上。

我做了一些 DOM 编辑：

我选择了octicon-organization作为图标， octicon-graph也可以。

现在在 Gitea 的 GitHub 贡献者图表上进行一些快速的 CSS 编辑并合并图像：

对于它的外观，这是一个非常粗略的想法，没有考虑到每个用户的个人图表。

看起来很棒^-^

@linusg太棒了！ 前进！

@lunny我现在有点困惑： @Morlinest是谁，他将在这个问题上扮演什么角色？

这可能是一个错误，或者他可能对我有一些秘密计划：D

@linusg @Morlinest :( 抱歉。像@Morlinest所说的那样犯了一个错误。我想将此问题分配给@linusg ，但我发现它不能分配给非维护人员并发布海报。

好的，感谢您的澄清：微笑：

哦，所以我现在必须这样做：D

给感兴趣的人的简短提示：我想在圣诞节假期做这件事，但找不到太多时间。 我已经创建了基本的东西（页面、路由等）并计划继续工作！

非常感谢^-^

好的，伙计们，还有一个更新。 我设法让它达到这个状态：

点击展开：

 


细节：

• 没有通过 HTTP API 公开数据，图形在服务器上呈现为 SVG（使用 https://github.com/wcharczuk/go-chart）。 这真的很高效并且让事情变得简单。
• 按提交、添加和删除的数量排序
• 用户界面“略”基于 GitHub 😄

遗留问题：

• 不在 gitea DB 中的贡献者（例如，因为 repo 已导入）将不会出现。 ✅
• 更大的存储库的性能问题。 可能只是我是一个 golang n00b。
• 从 X 轴移除 AM/PM 的东西（可以通过自定义格式化程序轻松完成） ✅
• 修复用户图的 Y 轴比例，1 次提交应该是 2 次提交高度的一半✅
• 适当的深色主题支持（上面的 CSS 在开发工具中进行了调整） ✅

可能的增强功能：

• 统计信息用于主分支（硬编码），可以轻松更改并作为 UI 控件公开

欢迎提出更改和改进的想法- 我已经退出了！ 我担心即将到来的代码审查：微笑：

呜呜……来了！ 现在是一些外部输入的时候了，所以请看下面的图片。

（gitea repo 取自 GitHub）

让我解释：

• 将显示不在 gitea 用户数据库中的用户，但没有指向配置文件 obv 的链接。 统计信息是按用户名计算的（每次提交只有“姓名”和“电子邮件”），这就是为什么在 GitHub 中只有“未知”、“未知”和“无闻”的原因：信息，这是克隆/导入 repo 时，所有相同的用户都会丢失。 我想这是最好的选择，想法？

• GitHub 每周编译统计数据，我使用每日统计数据。 这应该改变吗？

  这就是为什么 GitHub 上的 Y 轴以约 150 [每周提交数] 而 Gitea 以 52 [每天提交数] 结束的原因。 它还使 Gitea 上的图表出现更多“尖峰”。 （插值也不可用）

• GitHub 从统计数据中排除了合并提交，我没有实现任何此类（并且不知道将合并提交与普通提交区分开来有多难）。 我们想要这个功能吗？

• 您希望每个用户图表使用单独的颜色吗？

• 你觉得还有什么可以改进的？

表现：

我修复了我上一篇文章中提到的所有问题，我又回到了一些性能问题。 我的开发机器的所有统计信息：

Gitea 博客 repo 的贡献者页面加载需要 1.1 秒，这可能很好（_Page: 1090ms Template: 7ms_）

gitea 主 repo 的一个耗时 1 分钟 14 秒，并报告 _Page: 74443ms Template: 47ms_。 不过，它有 9 年的历史和近 7k 次提交。

可能的改进：gitea repo 贡献者页面最终有 602 个用户卡，我相信 GitHub 会在 100 个时截止。请参阅https://github.com/go-gitea/gitea/graphs/contributors。

你怎么看？

由于每次访问页面时都会遍历整个提交历史记录，因此我们也可以通过缓存统计信息来改善这种情况。 不知道这是否有意义以及实现的样子。

我必须清除 ServiceWorker 的缓存才能显示更改的 CSS 文件（正常的缓存刷新不起作用）。 我必须在这里做什么才能使其在 OOTB 中起作用？

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

@linusg 干得好！！！ 当存储库很大（即超过 1000 次提交）时，如何让其作为 cronjob 工作？ 它可以根据配置运行一天或多天。 我觉得top 100就够了，否则分页更好。

@linusg

• 统计信息用于主分支（硬编码），可以轻松更改并作为 UI 控件公开

也许您可以使用默认分支选项而不是创建另一个选项。

此问题已自动标记为过时，因为它最近没有活动。 如果在接下来的 2 周内没有进一步的活动，它将关闭。 感谢你的贡献。

不，仍在努力 - 有人可能会删除stale标签！

没有，还在做这个

这是个好消息，希望能尽快看到这个功能！
到处都可以看到图表和图形数据表示...

这是个好消息，希望能尽快看到这个功能！

很快 :tm:

时间对我来说绝对是个问题......在我对 golang 的基本不存在的知识旁边，哈哈。

我很高兴看到所有的兴奋（我也很兴奋，否则不会这样做！），但如果你们觉得这进展不够快（该死，已经半年多了），我可以对所有更改进行 PR，其他人可以帮忙吗？

很快™️

😅

但如果你们觉得这进展不够快

Naaah .. 谁关心你花在一个功能上的时间，如果它是一个非常好的和有效的功能？

我可以对所有更改进行 PR，其他人可以帮忙吗？

IDK，也许你可以在 GH 上公开发布你的 repo，这样其他人就可以 PR 你的 repo 并让它工作，这样你就可以 PR 官方的 repo 并整合它
或者，您可以在官方 repo 上为新分支打开 PR ，熟练且有时间意愿的人可以从中分叉和工作，然后 PR 代替，等待分支合并到 master 当然......

@linusg请发送一个 PR，也许有人可以在您缺席时帮助您。

期待这个功能。 现在陈旧了吗？ .....谢谢

这里还有什么消息吗？

PR 或分支曾经在这里提交过吗？

我想不是。 @linusg

我不认为我曾经推动我的改变。 甚至不确定我是否还有它们——对不起！