With redmine_git_hosting, repository view is not updated.

[crocket]

I have gitolite 3.0.4 , chiliproject 3.3.0 , git 1.7.12 , and the master branch of redmine_git_hosting. ruby version is 1.9.3.

With redmine_git_hosting, chiliproject fetches commits only when I register a git repo for the first time. autofetch feature doesn't work. And "rake redmine:fetch_changesets RAILS_ENV=production" doesn't update the repository view, either.

Without redmine_git_hosting, autofetch and redmine:changesets can fetch new commits into the database.

You should look into this.

[kubitron]

If you look at the README, this plugin is not guaranteed to work with gitolite 3.x.

However, your problem may be an issue with the post update hook or ruby configuration. This is a duplicate with issue #87. Please look at that bug and try what is suggested there (turn off caching to see if there is an actual problem with hook). I may end up closing this out.

[crocket]

After disabling git cache, I can see repository view updating. We should close this issue and work on issue #87 instead.

[kubitron]

Well, it turns out that you may have a different configuration problem, so let's leave it open.

Do you have any answers to my questions from that issue? (1) does the git user have access to Ruby?, (2) Is gitolite running on the same machine as Chili?

[crocket]

(1) Does the git user have access to Ruby? If I log in as the git user via bash, yes. Ruby is located at /usr/bin/ruby. But I don't know if the git user has access to ruby in redmine_git_hosting because it's a different execution environment. How do I know whether the git user has access to ruby in redmine_git_hosting's execution environment?

(2) Is gitolite running on the same machine as Chili? Yes, but, in init.rb, httpServer is project.snowberry.me, and gitServer is localhost. project.snowberry.me runs chiliproject and gitolite.

By the way, if Max Cache Time is set to "1 Minute or Until Next Commit" or "disabled", repository view can be updated. If Max Cache Time is "Until Next Commit", it's never updated.

[kubitron]

Ok. @crocket, I think that there was a Ruby 1.9.x problem with the update hook. Can you try pulling from master and see if it fixes things?

[crocket]

1) After pulling the master branch and setting Max Cache Time to "Until Next Commit", repository view is updated after I push new commits even if "autofetch" is turned off and "rake redmine:fetch_changesets RAILS_ENV=production" is not in a crontab.

I had the same problem with ruby 1.8.7 however. I will need to test your new commits with ruby 1.8.7 on my company's server tomorrow.

I wondered what you did to make "autofetch" and "rake redmine:fetch_changesets RAILS_ENV=production" redundant. So I disabled asynchronous hook execution and pushed for a test, and I saw the result below.

$ git commit -m "test 9" [master 19cd09e] test 9 1 file changed, 1 insertion(+) create mode 100644 test elisa@elisa:~/git/replaybuffer$ git push Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 279 bytes, done. Total 3 (delta 0), reused 0 (delta 0) remote: remote: remote: remote: Fetching changesets for replaybuffer's repository ... Done remote: remote: remote: To git:replaybuffer 87f1ac9..19cd09e master -> master

I don't know if "fetching changesets" was in the code before the last commit, but this is great.

2) Why do you enable asynchronous hook execution by default? I really am curious.

3) Do I have to consider the note below seriously also with postgresql? Important note: If using mysql for your database, you must make sure that the max_allowed_packet size is set (in, e.g., /etc/my.cnf) to be at least as large as the value you specify for Max Cache Element Size above. If you do not do this, you are likely to get very strange failures of the web server.

[kubitron]

So -- the behavior that you are seeing is the proper behavior. Pushes are supposed to be automatically reflected in Redmine/Chili -- there was just a problem with the hook with Ruby 1.9.x. If you have a problem with 1.8.7, that is something different, which we should fix. Please check. If everything is ok, let me know and close out this bug.

Note that the rake process is not entirely redundant. As I mention in the README, I suggest that you run a fetch_changesets operation regularly from the crontab to fix other random errors that might creep up in the gitolite configuration. When I first forked this plugin there were a lot more of such problems -- there are less of them now (but I still run it in my cron ever 15 minutes or so).

Asynchronous hook execution is a good idea -- otherwise you make the runner of git push wait for Chili/Redmine to run fetch changesets. When everything is working, there is no good reason to make them wait. Thus, I'd put it back as asynchronous.

As for (3), the issue is that the caching module stores data into the database of up to the Max Cache Element Size. In mysql, if this number exceeds the configured amount, then Chili/Redmine will crash. I don't know if posgresql puts a maximum limit on the size of records (sorry -- don't use it). However, if everything is working, it sounds as if you don't have to worry...

[crocket]

I don't know what happened. But somehow, today, on my company's server which has ruby 1.8.7, redmine_git_hosting without the "Make hook work with Ruby 1.9.x" commit successfully updated the changesets table when I pushed new commits.

Even after pulling "Make hook work with Ruby 1.9.x", redmine_git_hosting on my company's server fetches changesets on commits .

Is it solved, then?

[kubitron]

Sounds like it. I know that the hook works with ruby 1.8.7, since I use it on several production servers.

I'm going to close this bug. Let me know if you have any other problems (you can open a new bug). We will work on your https problem still (on bug #90).