좋은 그래프 라이브러리가 있습니까? 내 생각에 이것은 서버 측에서 렌더링 및 캐시 될 수 있습니다.

어떤 진전이 있습니까?

🎉

나는 이 기능에 대해 작업을 시작하고 싶습니다. 아무도 이미 사용하고 있지 않다면 (예, @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축은 커밋 수를 취하여 수행됩니다. 이는 전체 저장소(사용자 이름 무시)와 각 사용자(특정 날짜에 특정 사용자에 대한 모든 커밋 항목 가져오기) 모두에 대해 수행됩니다.

두 경우 모두 렌더링이 클라이언트 측에서 수행되므로 확대/축소로 동적 차트를 작성할 수 있다는 큰 이점이 있습니다.

여기의 일반적인 워크플로에서 작동한다면 이 문제에 할당해도 됩니다.

이것에 대한 몇 가지 생각이 더 있습니다. 건설적인 피드백은 물론 높이 평가됩니다!

UI에 페이지 링크 배치

그것은 잘 작동합니다. 지금은 구조를 조정할 필요가 없습니다.

링크에 대해 말하자면, 페이지는 아마도 https://git.example.com/<owner>/<repo>/contributors 에 있어야 하며, 이것이 다른 모든 링크가 작동하는 방식입니다.

내가 선호하지 않는 또 다른 아이디어는 활동 페이지에 기여자 그래프를 넣는 것입니다.

DOM 편집을 수행했습니다.

아이콘으로 octicon-organization 를 선택했는데 $# octicon-graph 도 작동할 수 있습니다.

이제 Gitea의 GitHub 기고자 차트에서 몇 가지 빠른 CSS 편집 및 이미지 병합:

이는 개별 사용자별 차트를 고려하지 않고 어떻게 보일지에 대한 매우 대략적인 아이디어입니다.

멋져보이네요 ^-^

@linus 좋아요! 가자!

@lunny 지금 좀 혼란스럽습니다. @Morlinest 는 누구이며 이 문제에서 어떤 역할을 할까요?

실수일 수도 있고 저와 비밀 계획이 있을 수도 있어요 :D

@linusg @Morlinest :(죄송합니다. @Morlinest 가 말한 것과 같은 실수입니다. 이 문제를 @linusg 에 할당하고 싶지만 비 유지 관리자 및 문제 포스터에 할당할 수 없다는 것을 알았습니다.

네, 설명해주셔서 감사합니다 :스마일:

아 그럼 이제 해봐야겠네요 :D

관심 있는 분들을 위한 짧은 안내: 크리스마스 휴가 동안 이 작업을 하고 싶었지만 시간이 많이 없었습니다. 기본 항목(페이지, 라우팅 등)을 만들었고 계속 작업할 계획입니다!

감사합니다 ^-^

좋아 여러분, 또 다른 업데이트입니다. 나는이 상태에 도달하도록 관리했습니다.

확장하려면 클릭하세요.

 


세부:

• HTTP API를 통해 데이터가 노출되지 않고 그래프가 서버에서 SVG(https://github.com/wcharczuk/go-chart 사용)로 렌더링됩니다. 이것은 정말 성능이 좋고 일을 단순하게 유지합니다.
• 커밋, 추가 및 삭제 수를 기준으로 정렬
• UI는 GitHub 😄을 기반으로 하는 "약간"입니다.

남은 문제:

• gitea DB에 없는 기여자는(예: repo를 가져왔기 때문에) 표시되지 않습니다. ✅
• 더 큰 저장소의 성능 문제. 저만 golang n00b일 수도 있습니다.
• X축에서 AM/PM 항목 제거( 사용자 정의 포맷터 를 통해 쉽게 수행할 수 있음) ✅
• 사용자 그래프의 Y축 스케일 수정, 1 커밋은 2 커밋 높이의 절반이어야 합니다 ✅
• 적절한 다크 테마 지원(위의 CSS는 개발 ​​도구에서 조정되었습니다) ✅

가능한 개선 사항:

• 통계는 마스터 브랜치(하드코딩됨)에 대한 것이며, 이는 쉽게 변경되고 UI 컨트롤로 노출될 수 있습니다.

변경 및 개선에 대한 아이디어를 환영합니다 . 지금까지 종료되었습니다! 하지만 다가오는 코드 리뷰가 두렵습니다 :스마일:

쏘... 갑니다! 이제 외부 입력이 필요한 시점이므로 아래 이미지를 참조하십시오.

(GitHub에서 가져온 gitea repo)

설명하겠습니다:

• gitea 사용자 DB에 없는 사용자가 표시되지만 obv 프로필에 대한 링크는 없습니다. 통계는 사용자 이름으로 계산됩니다(각 커밋당 "이름" 및 "이메일"만 사용 가능). 그렇기 때문에 GitHub에는 "Unknown", "Unknwon" 및 "无闻" 대 "Unknwon"만 있습니다. 정보는 다음과 같습니다. 리포지토리를 복제/가져올 때 동일한 사용자가 모두 손실됩니다. 그것이 가능한 최선의 선택이라고 생각합니다.

• GitHub는 매주 통계를 컴파일하고 저는 일일 통계를 사용했습니다. 이것을 변경해야합니까?

  이것이 GitHub의 Y축이 ~150[주당 커밋]이고 Gitea의 Y축이 52[일일 커밋]로 끝나는 이유입니다. 또한 Gitea의 차트가 더 많은 "스파이크"로 나타납니다. (보간도 사용할 수 없습니다)

• GitHub는 통계에서 병합 커밋을 제외합니다. 저는 이런 종류의 것을 구현하지 않았습니다(그리고 일반 커밋과 구별하는 것이 얼마나 어려운지 모릅니다). 이 기능을 원하십니까?

• 사용자별 차트에 별도의 색상을 원하십니까?

• 또 무엇을 개선할 수 있다고 생각합니까?

성능:

지난 게시물에서 언급한 모든 문제를 수정했으며 몇 가지 성능 문제로 돌아 왔습니다. 내 개발 머신의 모든 통계:

Gitea 블로그 리포지토리의 기고자 페이지는 로드하는 데 1.1초가 소요되며 이는 아마도 괜찮을 것입니다(_페이지: 1090ms 템플릿: 7ms_).

gitea 메인 리포지토리에 대한 것은 1분 14초가 걸리고 _페이지: 74443ms 템플릿: 47ms_를 보고합니다. 그러나 9년의 역사와 거의 7k 커밋이 있습니다.

가능한 개선 사항: gitea repo 기고자 페이지는 602개의 사용자 카드로 끝납니다. GitHub는 100개에서 잘 립니다. https://github.com/go-gitea/gitea/graphs/contributors를 참조하세요.

그것에 대해 어떻게 생각하세요?

페이지를 방문할 때마다 전체 커밋 기록이 탐색되므로 통계를 캐싱하여 상황을 개선할 수도 있습니다. 그것이 의미가 있고 구현이 어떻게 생겼는지 단서가 없습니다.

변경된 CSS 파일이 표시되도록 ServiceWorker의 캐시를 지워야 했습니다(일반 캐시 새로 고침은 작동하지 않음). OOTB가 작동하려면 여기서 무엇을 해야 합니까?

   

@linusg 잘 했어!!! 저장소가 클 때(즉, 1000개 이상의 커밋) cronjob으로 작업을 허용하는 것은 어떻습니까? 구성에 따라 하루 이상 실행할 수 있습니다. 상위 100개면 충분하다고 생각합니다. 그렇지 않으면 페이지 매김이 더 좋습니다.

@linusg

• 통계는 마스터 브랜치(하드코딩됨)에 대한 것이며, 이는 쉽게 변경되고 UI 컨트롤로 노출될 수 있습니다.

다른 옵션을 만드는 대신 기본 분기 옵션을 사용할 수 있습니다.

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 앞으로 2주 동안 더 이상 활동이 없으면 폐쇄됩니다. 귀하의 기여에 감사드립니다.

아니요, 아직 작업 중입니다. 누군가 stale 레이블을 제거할 수 있습니다!

아니요, 아직 작업 중입니다.

좋은 소식입니다. 이 기능이 곧 제공되기를 바랍니다!
어디에서나 차트와 그래픽 데이터 표현을 볼 수 있기를 바랍니다...

좋은 소식입니다. 이 기능이 곧 제공되기를 바랍니다!

곧 :tm:

시간은 확실히 나에게 문제입니다. 기본적으로 존재하지 않는 golang 지식 옆에 있습니다. 하하.

나는 모든 흥분을 보게되어 기쁩니다 (나도 흥분됩니다. 그렇지 않으면이 작업을 수행하지 않을 것입니다!). 그러나 이것이 충분히 빠르게 진행되지 않는다고 느끼신다면 (젠장, 반년이 넘었습니다), 나는 모든 변경 사항으로 PR을 할 수 있고 다른 사람이 도울 수 있습니까?

곧 ™️

😂

하지만 이것이 충분히 빠르게 진행되고 있지 않다고 느끼신다면

Naaah.. 아주 훌륭하고 작동하는 기능이라면 기능에 소요되는 시간을 누가 신경쓰겠습니까?

나는 모든 변경 사항으로 PR을 할 수 있고 다른 사람이 도울 수 있습니까?

IDK, 아마도 여기 GH에 귀하의 리포지토리를 공개적으로 게시하여 다른 사람들이 귀하의 리포지토리를 PR하고 작동하게 하여 공식 리포지토리를 PR하고 통합할 수 있도록 할 수 있습니다.
또는 숙련되고 시간이 필요한 사람들이 분기하여 작업할 수 있는 공식 리포지토리에서 새 브랜치에 대한 PR을 열 수 있으며, 대신 브랜치가 마스터에 병합되기를 기다리는 대신 PR을 열 수 있습니다.

@linusg 부재 시 도움을 줄 수 있는 PR을 보내주세요.

이 기능을 기대합니다. 지금은 낡았나요? .....감사 해요

추가 소식이 있습니까?

PR이나 지점이 여기에 제출된 적이 있습니까?

나는 그렇게 생각하지 않는다. @linusg

나는 내 변화를 밀어붙인 적이 없다고 생각한다. 아직 있는지 확실하지 않습니다. 죄송합니다!