search

kounoike / gitbucket-heatmap-plugin

Display your GitBucket contribution as heatmap graph
6 stars 2 forks source link

Count commits when plugin installing #2

Open kounoike opened 6 years ago

kounoike commented 6 years ago

In current implementation, it counts only CommitHook(ReceiveHook) executed. But many users has their repositories and they want to count their already exists commits.

McFoggy commented 6 years ago

looking at the migrate method of your plugin I am wondering it the process is synchronuous or asynchronuous. I imagine that it is synchronuous and thus I suspect it to be not so useable (because blocking during the update) on real production gitbucket installations.

Don't you think you should make it asynchronuous?

kounoike commented 6 years ago

@McFoggy I think that behavior is different depending on whether it is placed statically or dynamically. If plugin installed when GitBucket is stopped, migration step called synchronously. otherwise asynchronously.

It will be more carefully checked and documented such as

Don't use dynamic install. Please shutdown GitBucket before installing.
McFoggy commented 6 years ago

@kounoike Does gitbucket startup calls plugin asynchronuously? I doubt of that.

Because even if your migrate() method is called at startup of gitbucket before it is fully up and running I personally do not want to block my enterprise gitbucket installation just because the plugin is indexing all users/ and groups/all repositories/all commits. This should be a kind of batch action. I would also suggest to do it asynchronously even when you receive the hook call otherwise you are going to slow down the git push process just by indexing the commits.

kounoike commented 6 years ago

I think it is synchronously called at startup. I do not want to get complicated.

I checked counting time by git/git. It has 49,941 commits. It will be over in 10 seconds.

03:16:22.393 [Thread-28] INFO  CommitMigration - start HeatMap migration. Checking already exists repositories commits.
03:16:32.559 [Thread-28] INFO  CommitMigration - Commit check done.
McFoggy commented 6 years ago

OK but the problem is not unitary, because even if it takes only 1s per repository ; in my company we have more than 300 git repo hosted by gitbucket. So it means that your plugin will delay the startup by 300s = 5 minutes.

I do not want to get complicated

Neither do I but I think we can imagine a very simple way of handling that. I'll try to propose you a PR.

kounoike commented 6 years ago

hmm... @McFoggy your company doesn't allow scheduled 5 minutes downtime?

very simple way

It's interesting.

kounoike commented 6 years ago

This feature implemented in 20daa5d5667a024a80b29060117486c1ef6e6805. But we discus this implement.

McFoggy commented 6 years ago

your company doesn't allow scheduled 5 minutes downtime?

I have not said that but the 5 minutes add themselves to the time needed to make an upgrade. Currently it already takes me some 15-20 minutes to make an update of gitbucket (refuse new connections, block everyone, backup DB & git repos, update gitbucket & plugins, make verifications, reopen the system). So yes I am looking at every minute I can gain on this process, knowing that we have some 100 developers and a big Jenkins CI behind and that I do not want to do such update at 04:00 during night.

On the other hand, it is OSS software and I would perfectly understand that you are not interested in making it asynchronous if you do not need it.

Thanks already for providing this new plugin.