Fixed some stray semicolons that broke ChiliProject 3.0 on Ruby 1.9.2-p290

[gcymbalski]

So far, everything seems to be working swimmingly. This was the only real hangup. Thanks!

[kubitron]

Thanks for finding these. They are clearly syntax errors (not sure why Ruby 1.8 wasn't complaining).

So, would you say that ChiliProject 3.0 works well enough that I can put it on the list of compatible versions? I don't really run ChiliProject, and I have done some pretty deep hooks into Redmine to make this work more smoothly than it did before. I am pleasantly surprised that it is working...

Actually, it would be useful to look at the log and see if there is only a single call to the plugin for each operation (you can see this easily -- the opening stanza is something like "Fetching changes from gitolite-admin repository to..."). Eric's version of the plugin (which I started with) can end up calling the plugin 10s to 1000s of times for each operation, depending on circumstances; this property is one of the things I fixed. Also, try a "fetch_changsets" to see if that works properly. Finally, see if you can go to each user's edit page (as admin) and look at their "public_keys" tab. This is more recent functionality that I added as part of making things compatible with Redmine 1.3 and I am hoping that it works with ChiliProject 3.0...

Thanks for the work. I'll integrate this right away.

[gcymbalski]

I'm pretty new to ChiliProject and hadn't touched RedMine in years, so thanks for the suggestions on where to look for breakages. After setting up one project with a repo, setting up a user with a key, and experimenting with pushing and viewing from the plugin, it appears to be working as expected.

As for the logs, it looks like the plugin is behaving in a straightforward way - a single request generates what looks like a single call. Pushes trigger the postcommit hooks, which show up in Chiliproject's log, too. As for the fetch_changesets, I had mixed results..

• REST interface- Browser output: Access denied. Repository management WS is disabled or key is invalid. (Log: 403, Filter chain halted as [:check_enabled] rendered_or_redirected.) I could be doing something wrong here, though- I just enabled the REST interface, grabbed my user's WS key, and pasted it in (e.g. http://server/redmineroot/sys/fetch_changesets?key=xxx&id=1 ).
• Rake task: The only output is \ Execute redmine:fetch_changesets

I'd be happy to check other aspects of my setup, so feel free to toss out other things I should investigate. Thanks!

[kubitron]

Problem with http version of fetch_changesets sounds like a configuration problem. As for rake version, I was thinking that you should check the log file to see whether or not there is only a single call to plugin. I wasn't sure if you checked out the administrative settings page for a user. Does the public_key tab work?

Thanks for trying this out. Let me know if it continues to work as expected.

[gcymbalski]

re: REST fetch_changesets, I agree. I'm proxying this through nginx and will investigate further. Strangely, I'm not seeing any output like you mentioned- at least, nothing that looks like it's being generated by the plugin. The only times I see git-related messages in logs are when creating repositories. Is there some tweaking I should perform for more verbosity?

Also, the public_key tab works perfectly. Furthermore, I've been checking things in and out all day without issue, aside from occasional slowness (but this is on an ec2 micro instance, so a few seconds is not the end of the world). I haven't tried setting up remote repositories yet, but I can give that a shot another day.

[kubitron]

OK. I am slightly worried about something that you said above (sorry for the delay -- been traveling). When you execute a "fetch_changesets" operation, you should see something like the following in the log (granted, this is from Redmine, but should be similar):

Processing SysController#fetch_changesets (for 128.32.37.213 at 2012-02-22 13:30:01) [GET] Parameters: {"key"=>"elsP2QBqLKh6UclLlP2B"}
Executing RESYNC_ALL operation on gitolite configuration
Fetching changes from gitolite-admin repository to /tmp/redmine_git_hosting/git-tess/gitolite-admin
Our hook is already installed
Completed in 1802ms (View: 0, DB: 63) | 200 OK [https://tessellation.cs.berkeley.edu/redmine/sys/fetch_changesets?key=elsP2QBqLKh6UclLlP2B]

Notice the reference to "RESYNC_ALL". That is saying that the plugin's fetch_changesets code is getting triggered (to repair any weirdness that might have happened in the gitolite configuration). Do you see this in your logs?

[gcymbalski]

Indeed!

Processing SysController#fetch_changesets (for 62.135.4.32 at 2012-02-23 06:55:08) [GET]
  Parameters: {"key"=>"GADL7epRZUXqghEvLjyL"}
Executing RESYNC_ALL operation on gitolite configuration
Fetching changes from gitolite-admin repository to /tmp/redmine_git_hosting/gitolite/gitolite-admin
Our hook is already installed
Completed in 1353ms (View: 0, DB: 5) | 200 OK [https://testclient1/project/sys/fetch_changesets?key=GADL7epRZUXqghEvLjyL]

Sorry for the confusion– I had misconfigured my webserver, apparently, and the plugin has been working well for me over the last few days. Thanks again!

[kubitron]

Great. So, perhaps I can include Chili 3.0 in the list of compatible releases?

[gcymbalski]

It certainly seems compatible so far. I'm not well-versed in what changed between ChiliProjects 2.x and 3.x, but I haven't had any issues thus far. Thanks again for your work on the plugin!