Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement contributors graph #27882

Merged
merged 190 commits into from
Feb 15, 2024
Merged

Implement contributors graph #27882

merged 190 commits into from
Feb 15, 2024

Conversation

sahinakkaya
Copy link
Contributor

@sahinakkaya sahinakkaya commented Nov 2, 2023

Continuation of #25439. Fixes #847

Before:
image


After:
image


Overview

This is the implementation of a requested feature: Contributors graph (#847)

It makes Activity page a multi-tab page and adds a new tab called Contributors. Contributors tab shows the contribution graphs over time since the repository existed. It also shows per user contribution graphs for top 100 contributors. Top 100 is calculated based on the selected contribution type (commits, additions or deletions).


Demo

(The demo is a bit old but still a good example to show off the main features)

Screen.Recording.2023-07-11.at.10.51.37.mov

Features:

  • Select contribution type (commits, additions or deletions)
  • See overall and per user contribution graphs for the selected contribution type
  • Zoom and pan on graphs to see them in detail
  • See top 100 contributors based on the selected contribution type and selected time range
  • Go directly to users' profile by clicking their name if they are registered gitea users
  • Cache the results so that when the same repository is visited again fetching data will be faster

Issues to consider before merging

  • For big repositories, time required to fetch the data increases dramatically. We might consider setting a cron job as @lunny mentioned which I have no idea how to do so. (this is fixed 🥳 we now have cache. Cron jobs would be even better but I think caching is good for now. Maybe we can add cron job in another PR)
  • Again, for big repositories, updating all charts at the same time (while zooming, panning etc.) might cause performance issues. I don't experience this on my computer but I didn't test it on a low end device.
  • When contribution type is changed by user, whole page is re-rendered causing fetching the same data again which is unnecessary. This can be easily avoided by passing only the selected option to Vue. But I don't know how to do it so I need help here. (this is fixed 🥳)
  • Following issues are related with each other and likely to be fixed together (these are also fixed 🥳):
    • When contribution type is changed by user, we probably need to sort per user graphs based on the selected contribution type and not commits (which is default).
    • When user zooms or pans the graphs, we need to update title of the page to show correct dates. Currently this is hard-coded. (From repository start date - To current date)
    • When user zooms or pans the graphs, we probably need to update statistics on per user graphs (x commits, y additions, z deletions) to account only commits from the selected date range. Currently, they are calculated from start date to end date and sorted by total commits.
  • I don't know how to handle the errors so you might see things like iDontCareAboutErrors, _ := someFunc() while reviewing the code :D We probably need to handle them correctly so please point me in the right direction.
  • Most of the code I wrote is taken from other places in this repository and modified to fit my needs. Sometimes I encountered permission related code and I didn't bother to implement proper permission check for this feature. So I just used them as is. All the permission related code is taken from Pulse (formerly Activity) page. We probably need to change them and implement proper permission check.

@sahinakkaya sahinakkaya marked this pull request as draft February 15, 2024 08:29
@sahinakkaya
Copy link
Contributor Author

09d5d27 is probably breaking my code. It should not generate sundays (or start dates) based on user's local time zone because sometimes some countries change their clock and this will cause all the generated timestamps to be shifted. Then, it won't match the timestamps generated from backend, and will result in empty spaces in graphs:

image

I will mark as 'ready for review' again once I fix this.

@sahinakkaya sahinakkaya marked this pull request as ready for review February 15, 2024 09:00
@silverwind
Copy link
Member

silverwind commented Feb 15, 2024

09d5d27 is probably breaking my code

Hmm I did carefully check that the function's output is the same before and after the change, are you sure?

We should add a small unit test for this function to ensure correct output, I can do that later.

@sahinakkaya
Copy link
Contributor Author

Hmm I did carefully check that the function's output is the same before and after the change, are you sure?

yeah, I am sure. It might have worked because maybe in your country, you don't advance clocks to save day time. Here is what I am talking about: https://en.wikipedia.org/wiki/Daylight_saving_time

@silverwind
Copy link
Member

silverwind commented Feb 15, 2024

Okay, sorry for that. I will add a unit test to the function in a bit. The comment you added seems a bit hostile, and I think instead of such comments, we should just have proper unit tests that confirm the functionality.

@sahinakkaya
Copy link
Contributor Author

sahinakkaya commented Feb 15, 2024

Okay, sorry for that. I will add a unit test to the function in a bit. The comment you added seems a bit hostile, and I think instead of such comments, we should just have proper unit tests that confirm the functionality.

No, I didn't want to be mean. I am sorry if it sounds like that. As most of the people here, english is not my main language so I guess that's the problem. I didn't want to offend anyone in any comment of mine.

Yes, a unit test might be good 👍 Would you like to add it?

@silverwind
Copy link
Member

Yes I will add it. It's likely a good use case for a snapshot test.

@silverwind
Copy link
Member

silverwind commented Feb 15, 2024

I moved the three functions and added a simple test. As I understand it, that test should succeed when ran in every time zone because start and end day are Thursdays.

@sahinakkaya
Copy link
Contributor Author

sahinakkaya commented Feb 15, 2024

As I understand it, that test should succeed when ran in every time zone because start and end day are Thursdays.

Nope, testing against thursdays is not different from testing against sundays. Backend code generates timestamps with UTC+0 and it will never advance clock for 1 hour. (i.e. There will be always 168 hours between two consecutive sundays, or tuesdays or thursdays etc.) But some countries advance their clock for 1 hour at certain times of the year. That means sometimes there will be 167 or 169 hours between two consecutive sundays, tuesdays or thursdays etc. Frontend code knows about this change because it uses local time zone to process date related things. So it won't match timestamps generated from backend on some countries if you just say list all sundays with time 00.00

That's why adding 7*24 hours instead of 1 week works.

This is the best way I could explain. I hope it is clear.

@silverwind
Copy link
Member

silverwind commented Feb 15, 2024

I think you misunderstood. I mean time when tests run can vary 24h between time zones and such issues are very common with unit tests that involve time often to the point that one has to "freeze" time during tests to get stable results. By using thursday, a timestamp can only shift by at most 24h via timezone offset, so it won't shift into the next or previous week.

@silverwind
Copy link
Member

silverwind commented Feb 15, 2024

Let's merge this in 24h. I think it's good enough and the change to Monday can follow separately.

@6543 6543 merged commit 21331be into go-gitea:main Feb 15, 2024
26 checks passed
@silverwind
Copy link
Member

@sahinakkaya thanks for you work and also for your persistance 👍.

@sahinakkaya
Copy link
Contributor Author

Thank you everyone who contributed by their comments, reviews, and suggestions. I learned a lot in this process. And hey, we have a lovely contributors page now! 🥳 🎉

zjjhot added a commit to zjjhot/gitea that referenced this pull request Feb 16, 2024
* giteaofficial/main: (23 commits)
  Remove jQuery from SSH key form parser (go-gitea#29193)
  Refactor request function (go-gitea#29187)
  Docker Tag Information in Docs (go-gitea#29047)
  Fix gitea-action user avatar broken on edited menu (go-gitea#29190)
  Disable parallel Make execution (go-gitea#29186)
  Auto-update the system status in admin dashboard (go-gitea#29163)
  Avoid vue warning in dev mode (go-gitea#29188)
  Update JS and PY dependencies (go-gitea#29184)
  [skip ci] Updated translations via Crowdin
  Implement contributors graph (go-gitea#27882)
  Add support for action artifact serve direct (go-gitea#29120)
  Advertise WebAuthn support (go-gitea#29176)
  Tweak repo header (go-gitea#29134)
  Change webhook-type in create-view (go-gitea#29114)
  Remove jQuery from the comment task list (go-gitea#29170)
  Fix can not select team reviewers when reviewers is empty (go-gitea#29174)
  move sign in labels to be above inputs (go-gitea#28753)
  Refactor locale&string&template related code (go-gitea#29165)
  Extract linguist code to method (go-gitea#29168)
  bump to use go 1.22 (go-gitea#29119)
  ...
@go-gitea go-gitea locked as resolved and limited conversation to collaborators Feb 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. modifies/translation size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Contributors graph